Databases
StackOverflow2013
Postsdbo
POSSL response getting split over two callbacks
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POSSL response getting split over two callbacks
    primarykey
    data
    text
    <p>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.</p> <p>Things are supposed to go like:</p> <ol> <li>client opens socket connection and starts http handshake</li> <li>server completes http handshake</li> <li>client sends message to server and server sends reply</li> <li>client handles reply</li> <li>repeat 3 &amp; 4</li> </ol> <p>The client module implements</p> <pre><code>handle_info({Transport, Socket, Data}, StateName, State) -&gt; ... do stuff with data ... </code></pre> <p>which is called by the underlying transport (gen_tcp or ssl) when data shows up.</p> <p>Everything works fine when I configure the client and server to use <code>gen_tcp</code>. When I instead use <code>ssl</code>, the websocket handshake completes, but in step 4, I'm getting a callback to <code>handle_info</code> that contains only the first byte of data returned from the server. A subsequent callback will contain the remainder of the response.</p> <p>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 <code>ssl</code> (but not websockets or cowboy) that similarly do not exhibit this behaviour.</p> <p>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.</p> <p><strong>Update:</strong> 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.</p> <p>I did notice a couple things though:</p> <ul> <li>the first set of two callbacks always contains exactly one byte</li> <li>that byte is always 130 (0x82)</li> </ul> <p>No idea if that's relevant or not.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USAwesomeTown
    1. USAwesomeTown
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POSSL response getting split over two callbacks
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POSSL response getting split over two callbacks
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POSSL response getting split over two callbacks
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSince @EJP mentionned you can't rely on tcp boundaries the way you do, solving it by waiting for *exactly* two callbacks to occur may work for now, but may break in some unexpected cases or just with a future release of Erlang. You should rather accumulate the binary parts until you have effectively everything you need to at least do part of the work. What's garanteed is that on the same socket, different messages won't interleave.
      singulars
      1. POSSL response getting split over two callbacks
      1. USmatehat
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload