[nanomsg] Re: NN_MAX_SOCKETS / socket overhead
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 12 May 2014 14:43:53 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Drew,
My feeling is that what you really want to get somewhere into the
middle between plain old TCP sockets and full-blown nanomsg sockets.
That's exactly what can be done by implementing a new SP protocol
(check the API in protocol.h).
Martin
On 12/05/14 13:55, Drew Crawford wrote:
> In my quest to get session support added to nanomsg, an abstraction
> that is generally useful is a muxing device, that can split a
> heterogeneous message stream into smaller homogeneous streams
> according to the session ID, and also the inverse. I think this is
> a problem that has applicability beyond sessions specifically since
> there are many applications that may want to route a message
> according to application-specific rules. Something like:
>
>
> However it occurs to me, no matter what the muxer implementation
> looks like, it involves creating a pretty large number of sockets,
> several for each remote client. A server machine may want to
> support a lot of clients, so this may blow past the 512 SP limit in
> NN_MAX_SOCKETS very easily.
>
> I don’t have a good intuition for how lightweight a socket is. Is
> it intended that one could raise NN_MAX_SOCKETS and support
> thousands or tens of thousands of sockets in-process with an
> architecture like this? Or is this a job where raw sockets would
> perform a lot better without worrying about NN_MAX_SOCKETS limit?
> Or is this a situation where they are both too heavyweight and very
> large fanout muxing / demuxing is not a realistic goal?
>
> Drew
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTcMIJAAoJENTpVjxCNN9Y5PMH+gP22SnnlYeLTvB8mifwKxGU
Mk6fPwDUtLiDRlQ/SmY6TiFfKqxQpx/h5wwsZ7NY+22ajKMcxENcprWlQjB019VP
1b3WnCGch69rFSizjPjnxJQqeNI44k580IUWH30FycYINVgLydLmbI22pYDuahf3
O5uQ+Pfh6GQGdvtBycMgmAxGkBL0X6YEv+cOD2U2NlMz2pHsbu8YfIuQ7Zd5HI3F
OyFXRseYevkXHY/fmEXWIHAimSnhkzTdCbXQtHrtHkn9oXic6SYoOtPCAO6/Ma9+
Y4R7L3Eb4Nbh71bG7KV8YYz3U5xXFpyr2K+RaogbmUf/zK2T4gjJ/YcU7Vi/+yo=
=8xVD
-----END PGP SIGNATURE-----
Other related posts:
