What reasons would SDLNet_TCP_Send block for? |
Eliott Coyac
Guest
|
From: coyotte508 at hotmail.com
To: sdl-announce at libsdl.org Subject: SDL_net sending procedure Date: Sun, 7 Jun 2009 19:06:07 +0200 Hello the doc is here: http://www.libsdl.org/cgi/docwiki.cgi/SDLNet_TCP_Send there is something bothering me with that statement: "SDLNet_TCP_Send sends the data over the socket. If the data cannot be sent immediately, the routine waits until all of the data may be delivered properly (it is a blocking operation). This routine is not used for server sockets." What may cause the data not to be sent immediately? I mean, is it only in case the socket is already in use (which means i can prevent the problem from happening) or are there other causes I have no influence over? What's more, "This routine is not used for server sockets." . Then what is used? UDP? or another library? The thing is, actually, I can thread it allright, but it would sadden me having to use SDL_KillThread because for some reason SDLNet_TCP_Send is blocked and won't unblock. Or maybe there is a delay past which the function fails? Help! Thanks a lot :) Eliott _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090607/412ddd1d/attachment-0001.htm> |
|||||||||||
|
What reasons would SDLNet_TCP_Send block for? |
Brian
Guest
|
Hi.
TCP stands for Transmission Control Protocol. This means that it tries to limit the amount of data on the network to a manageable size, one that the receiver and the network itself can deal with. Part of the protocol is negotiating a "sliding window", the amount of data that TCP allows on the network. Part of determining this window size is the receiver - it will advertise their receive window (the size of the buffer on the receiving socket), and the sender basically agrees to not send more than that amount data. If the sending program tries to send more data, TCP will block it until it receives some acknowledgements from the receiver. TCP uses timeouts, so if the receiver is judged to be inactive then a send() operation will eventually return an error. You should never get an infinite block, but you can get very long ones (relative to what your program wants to do). With raw sockets, it is possible to place them into a "non-blocking" mode, which means that any operation which you try that would block instead returns an error "this operation will block right now". This allows your program to continue processing without using multiple threads (a thread per client can be expensive way of networking). The current SDL_Net API does not expose this functionality. As for server sockets, their only purpose is to act as a sort of "factory" for actual connections. It doesn't send or recv and information itself. So with a server socket you use SDLNet_TCP_Accept() and then use the SDLNet_TCP_Send() and SDLNet_TCP_Recv() functions on the accepted socket. On Sun, Jun 7, 2009 at 6:15 PM, Eliott Coyac<coyotte508 at hotmail.com> wrote:
|
|||||||||||||
|
What reasons would SDLNet_TCP_Send block for? |
Eliott Coyac
Guest
|
Ok, thanks a lot.
That's a relief :)
_________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090607/75b7120a/attachment.htm> |
|||||||||||||
|
What reasons would SDLNet_TCP_Send block for? |
MrOzBarry
|
Doing a recv on a socket, by it's nature, blocks until data is actually received. You need to look into SDL_net socket sets, which will let you check sockets before doing a recv on them.
For a much better explanation on why recv blocks, check out Beej's Guide to Network Programming, which is hands down the most readable and educational guide about cross-platform network programming. There are a few translations, too, if English is not your primary langnuage. -Alex On Sun, Apr 26, 2015 at 4:18 AM, zellJunior wrote:
|
|||||||||||||
|