[Libwebsockets] libwebsockets : Query related to max connections supported, I/O mechanism and message posting
jain.ayush09 at gmail.com
Mon Dec 9 12:49:59 CET 2013
Thanks a lot for your response.
I just had some more queries further inline, would be glad If you can
respond them as well.
On 12/5/13, Andy Green <andy at warmcat.com> wrote:
> ayush jain <jain.ayush09 at gmail.com> wrote:
>>It's been a week or so I started up researching on websockets and I
>>up here as I found a lot of interesting things about libwebsockets.
>>I was seeking some help regarding some aspects about the library in
>>of performance, I/O mechanism and message posting.
>>1) Is there any kind of bottleneck or performance issues (if it has
>>tested) in case I wish to integrate the same to a server supporting
>>200k simultaneous tcp/tls connections?
> Well something will always limit performance. Lws should give very good
> performance for one process context it's running in. Having a multicore cpu
> won't help that one process much.
> So if you want strong performance on huge numbers of sockets you should
> think about spreading it across multiple instances that have some kind of
>>2) I see there are 2 ways related to internal/external I/O mechanism
>>integration. But I see the API (libwebsocket_service_fd) takes in
>>structure as argument, Can I use the libwebsocket library with my
>>Epoll implementation when I use external I/O other than POLL, as there
>>would be lot of inactve FD's in my case? Or I need to stick to POLL? I
>>don't have poll mechanism in my server.
> The lib either uses internal poll loop or interfaces to some kind of
> external polling loop with an api that uses pollfd semantics.
> There's no requirement the external loop actually is using poll(), so long
> as you set and interpret the pollfd api parts appropriately that's enough.
Let's say am using epoll for tcp handling. Once I accept the
connection using accept(), let's say I register my dataRecv callback.
As and when I get read events from EPOLL, my dataRecv() callback would
be called which in-turn would call recv() in a stream way with
boundary getting governed by application level protocol.
Since websocket preserves the boundary, I should be able to receive
the message (just like I receive a datagram in UDP) when I get
LWS_CALLBACK_RECEIVE in the callback function for my application
protocol. I should somehow map my FD (on which I was calling recv())
to pollFD structure and call libwebsocket_service_fd() instead of
recv(). Please let me know if my understanding is correct?
>>3) When we say libwebsocket is single threaded, Do we mean that for all
>>send and receive using the library, I need to make sure (in case am
>>implementing server) that the call to libwebsocket_service_fd() and any
>>message posting by requesting callbacks happens in 1 thread? I mean
>>whatever response my server needs to post back to client after
>>of request, How am I going to save or store that data when I get a
>>once my server side socket is writeable?
> What it means is that all your interactions with lws must occur from the
> user callback code.
> You can allocate per connection user storage, you would do something like
> manage a per-connection fifo in there and spill it on the writable callback
> while it still had something waiting to go.
Thanks for clearing the same. That means that doesn't matter from
which thread am calling, as the sending as well as receiving of data
would be done from user callback code. Whichever thread my control
would be in, would have to request callback so it should take care.
As per my understanding, I would have to allocate space per connection
by specifying 'per_session_data_size' and 'rx_buffer_size' for sending
as well as receiving. In case the server wish to send out data,
libwebsocket_callback_on_writable() has to be called by saving the
data in 'wsi->user_space', which would be accessible during the
'LWS_CALLBACK_SERVER_WRITEABLE' callback. While receiving any data,
the same would be something like 'void *in' in the callback during
'LWS_CALLBACK_RECEIVE' (and the length would be max which we have
specified in 'rx_buffer_size'. Please let me know if my understanding
is correct here?
>>I know am asking too much of information here, but would really
>>if can respond to the same. Looking forward to your response.
>>Thanks in advance.
>>Libwebsockets mailing list
>>Libwebsockets at ml.libwebsockets.org
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Libwebsockets