Order of receiving response to TCP stream

[NotionCommotion]

A C++ client sends the following messages to a ReactPHP server via TCP sockets, and the server responds as shown.  Communication is asynchronous and non-blocking, and it is possible that the client will send these three messages before receiving a single reply.

 

Will the client always receive the server's responses in the same order (i.e. receive Message 1 first, then Message 2, and then Message 3)?

--> {"jsonrpc": "2.0", "method": "myMethod", "params": {"message": "Message 1", "someData": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}


--> {"jsonrpc": "2.0", "method": "myMethod", "params": {"message": "Message 2", "someData": 33}, "id": 4}
<-- {"jsonrpc": "2.0", "result": 29, "id": 4}


--> {"jsonrpc": "2.0", "method": "myMethod", "params": {"message": "Message 3", "someData": 22}, "id": 5}
<-- {"jsonrpc": "2.0", "result": 14, "id": 5}

 

[NigelRel3]

I think it depends on if this is made with a single connection or each request is made with a new connection.  Multiple connections may mean that the order they get delivered isn't a reliable factor.  But there again, they may be processed in any order and come back in any order anyway!

Is this something that is important with what your doing?

[NotionCommotion]

I think it depends on if this is made with a single connection or each request is made with a new connection.  Multiple connections may mean that the order they get delivered isn't a reliable factor.  But there again, they may be processed in any order and come back in any order anyway!

Is this something that is important with what your doing?

 

It will be a single connection.

 

Why I am asking?  I originally needed to know this as the client needs to save the data if not received by the server, and I thought the answer would sway the solution.  After thinking about it, I think a solution exists regardless (i.e. save messages sent in array based with index jsonrpc id, delete that array element upon response from server, and store all remaining array data upon disconnect).  I still, however, am curious whether the responses will be returned in the same order.

It will be a single connection.

[requinix]

When in doubt, Wikipedia.

 

tl;dr: they will be in order.

[NigelRel3]

When in doubt, Wikipedia.

 

tl;dr: they will be in order.

I think this is only for the packets in a single request - what I think he is doing is making three requests, but using the same connection (connections are usually the slowest thing to get set-up).  

Each request will be processed separately by the server and sent back as 3 responses.  The order they are processed and sent/received depends on how long each request takes to be processed and that can be dependent on all sorts of things.

[requinix]

Right, but it sounds like the question is whether a peer's three messages A, B, and C, sent in that order, will be received in that order by the other end. If those are "requests" from a client then the server could certainly process and respond to them in another order, say B, C, and A, but once the "responses" are sent they'll be received in that same order.

[NotionCommotion]

Correct, sent and received, and if the server actually sent them back in a different order, they would then be received in that different order.

 

So, if I sent a big old fat message to a given uri, and then immediately afterwards sent a tiny message, what allows the big message from getting there first?

[requinix]

*coughwikipedia*

 

TCP marks each packet with a sequence number, incrementing as more are sent. Though the packets themselves may arrive at any time and in any order, the machine on the receiving end will reassemble the packets in the correct sequence and deliver them to the waiting application.

[NigelRel3]

but once the "responses" are sent they'll be received in that same order.

That would be the case if they were all part of the same network payload. BUT they are 3 separate responses.  If you look at a web page and the way it requests all of it's components, the order which they are requested will always be the same (from the source code) but the order in which they are returned varies (try it using inspect in Chrome and watch the network tab)

TCP will just ensure that if a single message being sent in various packets by various routes will always be assembled at the receiver in the correct order.

[requinix]

If you look at a web page and the way it requests all of it's components, the order which they are requested will always be the same (from the source code) but the order in which they are returned varies (try it using inspect in Chrome and watch the network tab)

Browsers use multiple connections.

[kicken]

If you're using a single connection then the order that the responses are received will match the order they were sent, tcp guarantees this.

 

Now whether your server sends responses to requests in the same order as the requests were received depends on how you code your server to process those requests. If you always complete a request and send it's response before moving on to the next request then the request-response order will match. If you process multiple requests at once and send responses as soon as they are available then you might send them in a different order than the original requests.

 

For JSON-RPC the order of requests and their responses isn't important really, you can link everything up by the ID associated with the request / response.

[NotionCommotion]

*coughwikipedia*

 

TCP marks each packet with a sequence number, incrementing as more are sent. Though the packets themselves may arrive at any time and in any order, the machine on the receiving end will reassemble the packets in the correct sequence and deliver them to the waiting application.

Sorry, I will read this article in detail before asking additional questions on this subject.

 

For JSON-RPC the order of requests and their responses isn't important really, you can link everything up by the ID associated with the request / response.

Yes, agree.  I initially thought it was important, but came to the same conclusion.