CODEWITHSUNDEEP
c++websocket
user2872173
user2872173

Reputation: 35

websocket fin bit in c++

im' having lately a little problem with websockets fin bit and my c++ server. Whenever i try to use FIN = 0, host drops connection with no reason. Here is part of my code to calculate FIN:

string ret
ret += (unsigned char)((fin & 1) << 7) | (opcode & 63);

When i use FIN = 1, my first byte in frame is 129, which is correct and user gets correct answear. With FIN =0 first byte is 1 which also seems to be good and then after sending connection drops. Tried to send the same packets of data with both flags and only FIN =0 fails;

Why i try to use FIN = 0? well i'm trying to make a little three.js + websocket game, i'd like a server to send all the models through the websocket for every player, so i expect a heavy load which i'd like to control.

I'd be happy to provide any additional informations.

Thanks in advance.

Upvotes: 1

Views: 1609

Answers (2)

obeid salem
obeid salem

Reputation: 147

OPCODE:

 |Opcode  | Meaning                             |  |
-+--------+-------------------------------------+-----------|
 | 0      | Continuation Frame                  |  |
-+--------+-------------------------------------+-----------|
 | 1      | Text Frame                          |  |
-+--------+-------------------------------------+-----------|
 | 2      | Binary Frame                        |  |
-+--------+-------------------------------------+-----------|
 | 8      | Connection Close Frame              |  |
-+--------+-------------------------------------+-----------|
 | 9      | Ping Frame                          |  |
-+--------+-------------------------------------+-----------|
 | 10     | Pong Frame                          |  |
-+--------+-------------------------------------+-----------|

Upvotes: 0

vtortola
vtortola

Reputation: 35905

I have no idea about C++, but I know a bit about WebSockets.

Which value do you have in the other byte? When you send a FIN=0 frame, you still need to send the frame options in it. Subsequent frames must be of the option "Continuation", and nothing else. As far as I remember, continuation frames cannot even have the RSV bits different than 0.

If you send a frame with FIN=0 without type (text or binary), it will probably fail. If you send a FIN=1 with a type different that "Continuation" after a FIN=0 will fail.

So the key is, what are you sending in the second byte? Also, it would be great if you try with Google Chrome and check in the console why is the connection being shut down.

Upvotes: 1

Related Questions