problems when enabling nonblocking i/o in udp socket

[noswitchport]

Hi,

I used C to write simple "udp" (not tcp) socket programming. The client will send the string to the server and server will just echo that string back to client. Everything went fine until I set the flag for client as nonblocking i/o (O_NONBLOCKING). When I sent the first string from client, the error occured and printed "Resource temporalily unavailable". But when I sent the second string from client, the server instead sent back the first. When I sent the third string from client, the server echoed the second, and so forth... I'm just curious what nonblocking i/o in client actually did to my code and made that a problem.

Thank you very much.

NOSW

[Banfa]

Non blocking means that the code will not wait for an event to happen before it returns a result where as blocking waits for something to happen.

You can't just switch from blocking to non-blocking, there require different programming structures.

Take your example, the server just echos the string it receives. so for this sequence

send "String 1"
receive

send "String 2"
receive

send "String 3"
receive

In blocking IO the receives will block until they receive something (or a timeout occurs). So when you send "String 1" and then receive the receive waits for the server to reply.

In non-blocking IO the receive will not wait to receive something, if there is something there it will return it otherwise it will return an error. Since the server is unlikely to have time to rely in the time it takes to move to the next statement after the first call to send "String 1" the call to receive results in an error because nothing is waiting to be received. The second time there is something waiting to be received, the reply from the first send so you recieve that.

To work for a non blocking socket the sequence needs to change to

send "String 1"
wait for notification of received data
receive

send "String 2"
wait for notification of received data
receive

send "String 3"
wait for notification of received data
receive

The useful thing about a non blocking socket is that you can set up your program so that it can receive unsolicited messages more easily (by having a thread sitting around waiting for received data while the main thread carries on doing other things).

[noswitchport]

Hello,

Thanks for a reply. I do understand the concept but what does "wait for notification of received data" mean in the code?

NOSW

[DeMan]

Usually, there is little point sending data unless you know the other end has recieved it. So you wait for an Ack (from Acknowledgement) that the data has been recieved. In some protocols, rather than you timing out when you haven't recieved an Ack, the client either times out between packets, or recieves packets in a different order to what is expected (eg outside the window he is working in). In this case, you should recieve a NAK (or Not Acknowledged).


Little bit off the Topic:
In simple protocols if you are sending one packet at a time, there is little point sending the next packets until you know tyhe fiorst has been recieved.

In more complex protocols, you may have a window of several packets (any of which the client is quite happy to recieve, because he can reconstruct the order). In this case Acks and NAKs are sent with the packet number that he has (or hasn't) recieved, to enable you to resend it. As the earliest packet in the window is recieved, the window moves to the next earliest non-recieved packet.