Question

I'm developing a client-server application and have been tasked with adding support for running over websockets. I'm using Cowboy on the server side, and have been working on an Erlang websocket client for testing.

Things are supposed to go like:

  1. client opens socket connection and starts http handshake
  2. server completes http handshake
  3. client sends message to server and server sends reply
  4. client handles reply
  5. repeat 3 & 4

The client module implements

handle_info({Transport, Socket, Data}, StateName, State) ->
    ... do stuff with data ...

which is called by the underlying transport (gen_tcp or ssl) when data shows up.

Everything works fine when I configure the client and server to use gen_tcp. When I instead use ssl, the websocket handshake completes, but in step 4, I'm getting a callback to handle_info that contains only the first byte of data returned from the server. A subsequent callback will contain the remainder of the response.

I'm really confused by this behaviour given that the same code with gen_tcp swapped in works fine, and we have two other transports built using ssl (but not websockets or cowboy) that similarly do not exhibit this behaviour.

Can anyone suggest what might be causing data to get split this way? I'd prefer not to have to write handling for this if I don't need to.

Update: Just for kicks, I modified the client so that it will wait for two callbacks to occur and will concatenate the data from both before trying to parse it. This solves the problem, but still leaves me baffled.

I did notice a couple things though:

  • the first set of two callbacks always contains exactly one byte
  • that byte is always 130 (0x82)

No idea if that's relevant or not.

Was it helpful?

Solution

There are no message boundaries in TCP. You don't have any right to rely on the behaviour you are expecting. The transport can give you data in whatever pieces it likes, as long as it provides it all, intact, in the correct order. TCP provides you with a byte stream, and most SSL libraries ditto (although at a lower level there are indeed SSL record messages).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top