Help, non-blocking sockets.

Networking and Multiplayer Programming

Started by ixuz January 23, 2009 01:34 AM

15 comments, last by kyoryu 15 years, 2 months ago

11,916

January 24, 2009 10:59 AM

Quote:On a UDP socket a packet could be dropped theoretically between the call to select and the receive function.

No, it could not. The packet has left the network, and is in the realm of the kernel. The guarantees of select() and recv() say that the packet cannot be dropped at that point.

Quote:But...
send on a socket in blocking mode blocks until the *whole* buffer has been consumed. At least on Windows. It might be different on other operating systems.

No, it does not, if select() says that the socket is writable, then a send() on that socket will not block. If that means that only half the buffer is consumed (on a TCP stream), then only half the buffer is consumed (and the amount consumed is returned).

enum Bool { True, False, FileNotFound };

ixuz

122

Author

January 24, 2009 11:03 AM

Hi, I acually managed it to work with non-blocking and select. I had problem accepting new clients, now my select() function tells me if a client wants to connect.

How about disconnects, should I ping all my clients all the time? Could anyone write down some pseudo code for your solution?

And thanks alot to all of you answering my questions, thank you!

// ixuz

imgty

116

February 04, 2009 11:55 AM

@hplus0603

Ok, you are right for the receive functions (and accept). select gives this guarantee:

Quote:If the socket is currently in the listen state, it will be marked as readable if an incoming connection request has been received such that an accept is guaranteed to complete without blocking. For other sockets, readability means that queued data is available for reading such that a call to recv, WSARecv, WSARecvFrom, or recvfrom is guaranteed not to block.

But you are wrong for the send functions:

Quote:If the socket is not processing a connect call, writability means a send, sendto, or WSASendto are guaranteed to *succeed*. However, they can block on a blocking socket if the len parameter exceeds the amount of outgoing system buffer space available.

hplus0603

11,916

February 04, 2009 12:08 PM

That's why send() accepts the DONTWAIT flag, although I don't think WinSock actually implements that :-/

enum Bool { True, False, FileNotFound };

kyoryu

224

February 05, 2009 01:07 AM

Trivia:

If you select() a socket for reading, and it returns that there is data available, but reading results in zero bytes read, this means...

Kylotan

10,510

February 05, 2009 07:32 AM

...that the remote peer closed the connection.

kyoryu

224

February 05, 2009 09:14 PM

Well, I figured you'd know the answer, being a moderator :)

It actually also turns out that with poll(), the ONLY sure way that you can tell (cross-platform) if a socket is closed is if it returns 0 bytes on a read, after poll claims it is readable.

Help, non-blocking sockets.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Help, non-blocking sockets.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines