Ok, thanks a lot.
That’s a relief :)> Date: Sun, 7 Jun 2009 19:08:31 +0100
From: brian.ripoff at gmail.com
To: sdl at lists.libsdl.org
Subject: Re: [SDL] What reasons would SDLNet_TCP_Send block for?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.
More than messages?check out the rest of the Windows Live?.
http://www.microsoft.com/windows/windowslive/