General timing problem in network programming

Question

Suppose that there're two types of packet in the chatting server. Those two packets are used for getting the status of another user. One(call this as REQ-STAT, RES-STAT) is request-and-response form and another one(NOT-STAT) is notification form packet.

For instance, if I send [REQ-STAT simpson] to the server and I may get [RES-STAT simpson online]. Or, if the user SIMPSON's status has been changed, I'll get the user's status like [NOT-STAT simpson offline].

Okay, the server is running on multi-core machine and using multiple threads, of course.

If the server get [REQ-STAT simpson] packet, the server will prepare packet [RES-STAT simpson online] - if the SIMPSON is online. At this point, the SIMPSON logged out, so the server send packet [NOT-STAT simpson offline] to the client. After the server sent [NOT-STAT simpson offline] packet, [RES-STAT simpson online] packet is sent

// the server lock during using user data structure but not for the whole process.

------[REQ-STAT simpson]------> simpson is online and prepare response packet

<--[NOT-STAT simpson offline]-- simpson has been logged out and send not packet

<--[RES-STAT simpson online]--- send response

// the latest packet does not have the latest information !!!

Can above scenario be happen if LOCK does not used for whole process? If so, do I should lock that all? Any other solutions?

Thanks.

Answer 1

Well it appears that you can solve it by the way the receiving program treats the different packets.

If the program asks if SIMPSON is online, it expects an answer of yes or no. But it should treat that as: SIMPSON was or was not online around the time I sent my request but he could have logged out 1 millisecond after this packet was created so I'm not guaranteed he's online now, I just know he was when I asked. Use this information for what it's worth.

However, when the program receives a "SIMPSON signed off" packet, then you know that SIMPSON signed off at the time specified in the packet. Receiving this would override any pending request for current status because you were just told that he signed off. So "abort" the current status request if there is one. By abort I mean gracefully stop that thread or ignore the result for that request.

Another option is to embed a high-resolution time stamp (which must be thread-safe) or a thread-safe, client-specific sequential counter into every packet so the client can figure out the order of events independent of the order of receiving them. Standard thread-safe programming practices will allow you to do this and it sounds like you're knowledgeable about that.