[Libwebsockets] [libwebsockets] #40: Blocking client connection

Trac trac at libwebsockets.org
Mon Sep 23 06:40:49 CEST 2013


#40: Blocking client connection
------------------------------------+-----------------
  Reporter:  JM                     |      Owner:
      Type:  defect                 |     Status:  new
  Priority:  major                  |  Milestone:
 Component:  libwebsockets library  |    Version:
Resolution:                         |   Keywords:
------------------------------------+-----------------

Comment (by agreen):

 What you're saying is reasonable but you should re-read what I wrote in
 comment 6

 ''When the connection is established and the protocol known, the socket
 options for the connection are changed to reserve protocol.rx_buffer_size
 space for transmit packets.
 So it's safe to assume that if you get signalled it's OK to write on that
 socket, that you can write up to protocol.rx_buffer_size on it (defaults
 to 4096 if left at 0).''

 It's not just handwaving you can see the code that does that here -->

 http://git.libwebsockets.org/cgi-
 bin/cgit/libwebsockets/tree/lib/handshake.c#n265

 Because of that you won't get signalled for write until you can send
 protocol.rx_buffer_size in one hit, without risk of only some being sent.
 Notice that if the reservation is not accepted by the kernel the
 connection is dropped right there, so if you have an established
 connection you can rely on this having been set on the socket.

 So the two choices are leverage that and set protocol.rx_buffer_size to be
 bigger than anything you'll want to send in one hit (the test apps take
 this approach), or if your max message size is bigger than what the kernel
 would accept in one hit, you need to use the fragmentation arrangements
 anyway.

--
Ticket URL: <http://libwebsockets.org/trac/ticket/40#comment:8>
libwebsockets <http://libwebsockets.org>
libwebsockets C library



More information about the Libwebsockets mailing list