[Libwebsockets] Some help wanted explaining how the dumb-increment-protocol works
andy at warmcat.com
Sun May 15 12:37:35 CEST 2016
On 05/15/2016 06:12 PM, Colin Adams wrote:
> On Sun, 15 May 2016 at 00:05 Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>> wrote:
> > >request Server Close button DOES work (debugging shows my handler
> >> >receives
> >> >the message, but it never receives a reset\n message when I press
> That's pretty confusing actually, if I understood it both buttons
> send something but only one makes it to the RECEIVE. And both those
> cases are dumb-increment (close test reuses a second dumb increment
> I think I inadvertently left tact in from an older message in this thread.
> Both reset and closeme requests reach my server.
Yes I saw it was quoted, but it only struck me thismorning how it would
be difficult to get that exact situation (and so maybe it's related to
what is happening).
> I think it'd be interesting to check with tcpdump -s0 -X what
> happened on the wire.
> That was a useful tip. As a result, I have now got lws_write working
> correctly (just a silly error on my part).
> >issuing an lws_close_reason, but that too isn't working. No doubt
> >facts are closely related.
> Yeah it's related to lws_write() again.
> Apparently not, as that works now, but lws_close_reason does not.
Hm. lws_close_reason() sets up some payload that goes out with an
lws_write() during the close sequencing. Without knowing why the other
lws_write()s were broken, it's still possible the same problem is coming
Again though, tcpdump should see the appropriate things going on when
you click the button in the original, and you can contrast that with the
sequence that breaks.
If there's a problem writing something, it should appear on the wire
broken or not appear at all when compared to the working sequence.
One way or another, something visibly different should be seen in tcpdump.
> I added the following statement at the beginning of lws_close_reason:
> printf ("Status is %i, message is %s, length is %u\n", status, buf,
> (unsigned int) len);
> and I get identical output from both the distributed C example, and my
> idris version.
> I'm suspecting it's due to being on a second connection. One thing I DO
> see that is different between the output of the two implementations (not
> related to lws_close_reason, apparently, as it occurs before that, but
> might give me a clue), is the following. Your C implementation puts out
> the following lines:
> lwsts: permessage-deflate requires the protocol
> (dumb-increment-protocol) to have an RX buffer >= 128
> lwsts: ext permessage-deflate failed construction
> lwsts: Capping pmd rx to 128
> lwsts: cache_len 313
> lwsts: Capping pmd rx to 128
> But when I run my implementation, I only see the first two lines, not
> the last three (same debug level). Are those last three lines relating
> to the other plugins (I've only tried implementing the dumb-increment
> one so far - one step at a time)?
Yes they are coming from another plugin with protocols.rx_buffer_size
of 128... permessage-deflate is adjusting his output buffer down from
1024 -> 128 to match.
For dumb-increment, his rx_buffer_isze is deliberately too small (so I
can test permessage-deflate dealing with that). He fails in the
extension construction, and so doesn't get to the adjustment bit that
So what you have there is OK if you only fed it dumb-increment.
More information about the Libwebsockets