Web socket - the order processing of req / resp

Question

0.00/5 (No votes)

See more:

I am sending a lot of requests to the webSocket server in a short time. Can I be sure that webSocket process the requests and respones in this order: reqA, reqB, reqC then the server responses to these requests in the same order resA, resB, resC ?

What I have tried:

I am sending a lot of requests to the webSocket server in a short time. Can I be sure that webSocket process the requests and respones in this order: reqA, reqB, reqC then the server responses to these requests in the same order resA, resB, resC ?

Posted 16-Apr-20 9:35am

Member 13702159

Updated 17-Apr-20 1:02am

Add a Solution

Comments

[no name] 16-Apr-20 15:49pm

no

Member 13702159 16-Apr-20 16:14pm

0x01AA - could you please elaborate on that ?

[no name] 16-Apr-20 16:28pm

a.) The basic protocol is TCPIP so the answers from the requests can be take completely different routes in the network. So, even the server does respond in the same order (like the request) you can not assume that answer will arrive in the same order at client side.
b.) You don't know how the server handles the requests, especally in situations where requests are distibuted to other servers (load balancing)

Member 13702159 16-Apr-20 17:05pm

What do you think about this?
https://stackoverflow.com/questions/14287224/processing-websockets-messages-in-order-of-receiving/31894114

Someone wrote here: " WebSocket IS TCP, which means that the order of delivery is guaranteed"

[no name] 16-Apr-20 17:22pm

TCPIP does inform you whether the information has successful send to the receiver (the request). But this has nothing to do with the response you excpect for the request you send.

Means you can send several requests successful, but you have no guarantee to 1.) receive an answer and 2.) the order the answers arrive

The only thing you can do is to serialze it:

Loop
1.) Send request
2.) Wait for answer

Or in case you are the one who program both sides (client and server), tag your requests

MadMyche 16-Apr-20 18:26pm

The "order" that is "guaranteed" is the fragments in that one request, not the order that the messages are received. Or processed

[no name] 17-Apr-20 17:16pm

Short and clear +5 ;)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Greg Utas · Answer 1 · 2020-04-17T01:03:00

TCP preserves order and has no concept of a "message". A message can be broken up into pieces, but the pieces will arrive in order. During the time that the TCP connection is kept up, the order of all "messages" will be guaranteed, but it is up to the endpoints to find the message boundaries by splitting or combining what is received on the socket. Many systems will shut down a TCP connection that remains idle, in which case the "keepalive" option must be used to prevent this.

This is not true for UDP, which can lose or reorder packets, but which will preserve message (individual packet) boundaries.