Sending several times without receive

[FRex]

What happens if I send a few times via udp or tcp without receiving anything on the other end(not that the other end dropped out or such, just that sends pile up before I receive them)?
I assume it's ok but might reorder the udp packets?

[eXpl0it3r]

binary has added some valuable stuff to the FAQ on networking, maybe it helps.

[FRex]

I guessed TCP is reliable, it doesn't really say for UDP but it makes me worry that I'll be polling my few TCP, listener and one or few UDP sockets for data every game cycle, at what point is it worth spawning a thread and placing a blocking selector there?
Would it make sense to call wait with extremely small timeouts(way under millisecond) each game cycle? I'd want to keep things mono threaded, UDP is going to receive and send new data every cycle anyway so there is no 'overhead' to be had there.

[binary1248]

You don't have to "block" with a selector. Just tell it to return immediately (in essence just pass it sf::Time::microseconds( 1 ), your application won't run fast enough for that to make a difference anyway ) and act if a socket is ready.

[Varonth]

It depends on how much data you are sending inbetween each subsequent receive call.

Each TcpSocket has a receive buffer, which will store data until it is read by it's recv function. If the buffer is full the other sides send will either wait until the it can actually send more data in case of a blocking socket, or in non-blocking mode return EWOULDBLOCK or EAGAIN.

The size of the Tcp buffer is depending on the system, for example MSDN says the standard receive buffer size in windows is 8192 bytes.

Edit:
Forgot to mention what a UDP socket does, but I guess that is pretty clear.
Cannot fit into the buffer? Well then... drop it ^^

Edit2:
Just looked at the SocketImpl at it appears that in case of an EWOULDBLOCK (and its windows equivalent WSAEWOULDBLOCK) error from the Socket, the SFML status would be Socket::NotReady, and in case of EAGAIN it would just be Socket::Error.