[noPoll] noPoll : Query related to I/O mechanism, max concurrent connections.

[ayush jain]

Hello Francis,

Would be really glad if you can respond back to my queries as on
16-Dec inline to help us finalize on the websockets library support :

On 12/16/13, ayush jain <jain.ayush09 en gmail.com> wrote:
Hi Francis,

Thanks a lot for your response. Got little delayed from my end due to
some other things I had to jump onto. (Also I was not sure if my
registration and post was successful as I guess the same is in
Spanish, I used a lot of goole translator :) )

Would really be glad if you can further throw some light on few more
queries of mine inline.

On 12/7/13, Francis Brosnan Blázquez <francis en aspl.es> wrote:
>>> Hello everyone,
>>
>> Hi There!
>>
>>> It's been a week or so I started up researching on websockets and I
>>> landed
>>> up here as I found a lot of interesting things about nopoll. Am very
>>> new to websockets thing, so request you to please don't mind in case
>>> something sounds funny :).
>> ;-)
>>
>>> I was seeking some help regarding some aspects about the nopoll library
>>> in
>>> terms
>>> of performance, I/O mechanism and message posting.
>>>
>>> 1) Is there any kind of bottleneck or performance issues (if it has been
>>> tested) in case I wish to integrate the same to a server supporting
>>> approx
>>> 200k simultaneous tcp/tls connections?
>>
>> Ok, it shouldn't be a problem (a part from the obvious resource
>> allocation
>> needed
>> to support that amount of connections...). Assuming you do support that
>> amount of connection, then noPoll will just add the enough "magic" ti
>> make each of those connections to run WebSocket.
>>
>> Maybe the biggest problem to consider here is the amount of memory+cpu
>> that requires wss:// (but not because websocket itself, but due to the
>> amount of resources to sustain a single TLS session).
>>
>>> 2) Does it provide support to integrate to the external I/O mechanism,
>>> lets say if I already have EPoll mechanism at place, and I wish to
>>> integrate the same into it?
>>
>> Sure! It comes with a built-in waiting loop for those cases you need
>> something simple, but in general, I think the target is to integrate it
>> into existing loops. This is what we have done with Turbulence [1] and
>> Vortex Library [2].
>>
>> [1] http://www.aspl.es/turbulence
>> [2] http://www.aspl.es/vortexlibrary
>>
>> You have more about here:
>>
>> http://www.aspl.es/nopoll/html/nopoll_core_library_manual.html#nopoll_manual_reading_content_from_connection
>>
>> Talking about this, an interesting feature that provides noPoll is port
>> sharing. This means you can run legacy+websocket on the same port. We're
>> using at Core-Admin [3] to support BEEP, BEEP over Websocket and BEEP
>> over secured WebSocket on the same port.
>>
>> [3] http://www.core-admin.com
>>
>> You've got more info about that here:
>>
>> http://www.aspl.es/nopoll/html/nopoll_core_library_manual.html#nopoll_implementing_port_sharing
>>
Thanks a lot for this info. I was also of the impression that noPoll
provides it internal select,poll and epoll I/O based on some switch.
But traversing the code I found out that only 'select' is implemented
as part of default. Does that mean we need to write our own waiting
mechanism in case we wish to use 'NOPOLL_IO_ENGINE_EPOLL' etc, and
also need to change e.g. 'nopoll_io_get_engine' as it didn't use
'engine_type' currently.
So my understanding is that in case we wish to use internal noPoll
I/O, we need to write wrappers and waiting mechanism (would need to
change library functions as well), and in case we need to integrate to
our existing I/O, we need to go as you have described.

When I tried to test concurrent connections using my client with
noPoll, I could not proceed more than 1050 connections (I guess the
limit due to default 'select' and my kernel limitation for the same).

>>> 3) Let's say if we implement websocket server, Can we do the receive
>>> handling in 1 thread for all the (say max 200000 sockets) and continue
>>> with send operation using multiple threads. In that case do we need
>>> any callback to check if the connection is ready?
>>
>> Under previous links you'll find everything about this. In short: you
>> can watch noPoll sockets as regular sockets (in fact they are). Once
>> movement is detected, call appropriate functions to get data received...
>>
>>> And also, would I
>>> need some locking before sending my data from any thread or its
>>> already taken care of in noPoll library?
>>
>> Ok, we've designed the library so it can work in threaded and
>> non-threaded scenarios. In this case you must provide the right
>> functions to let noPoll to create mutexes, destroy, lock and unlock
>> them... with this:
>>
>> http://www.aspl.es/nopoll/html/group__nopoll__support_ga7f2a26a896c1416b23933097a993a435.html#ga7f2a26a896c1416b23933097a993a435
>>
>> Then noPoll will use these at the right places...
>>
Nice! That's great. So we need to just initialize the global mutex,
and have to insert my lock/unlock etc API's inside those mutex
wrappers during 'nopoll_thread_handlers' and noPoll would take care of
appropriate locking and synchronization no matter which thread is
accessing the noPoll context at the same time. Please correct me if my
understanding is wrong here.
>> Let us to know your progress and any product using noPoll. We will be
>> glad to publish some references about it. BR
>>
:) Sure Francis. Would definitely update once we get a go ahead with
the websocket library.

>>> Would really appreciate your responses on the same.
>>>
>>> Regards,
>>> _Ayush
>>> _______________________________________________
>>> noPoll mailing list
>>> noPoll en lists.aspl.es
>>> http://lists.aspl.es/cgi-bin/mailman/listinfo/nopoll
>>
>>
>>