[nanomsg] Re: interesting performance figures
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 27 Mar 2014 08:51:29 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 27/03/14 06:41, Garrett D'Amore wrote:
> http://garrett.damore.org/2014/03/early-performance-numbers.html
The number look OK IMO. Doing alloc on the critical path may well
account for the loss of throughput -- nanomsg does 0 allocs on the
critical path.
> That’s my brief update on my work. I’ve added inproc, PAIR
> protocol support, and benchmarks (tests).
Nice!
> I know folks want UDP… I’m a little concerned about proceeding with
> UDP only because of the difficulty of keep track of pipes on a
> connectionless (and no keepalives) transport. For req/reqp, this
> could get ugly. I need to think about this more.
I would say we have to re-think the req/rep RFC.
UDP is meant to be connection-less or, in other words, stateless. We
should try to preserve this property.
Thus, instead of keeping track to all UDP nodes that have ever sent us
a message, we should put an IP address into the message's route-back
stack. That in turn should mean replacing 32-bit elements in the stack
by arbitrarily-sized elements.
> Its also unclear how pub/sub works in this case, since there isn’t
> an actual “connected” end point to keep track of. The semantics
> get… sticky. And as others have pointed out, there may be other
> concerns about enabling UDP (congestion control, etc.) I don’t
> know what the right answer here is. (For me, its to stick with
> TCP. :-) But my use cases are relatively simple and I’m not trying
> to stream or to multiplex a bunch of different things onto a single
> TCP channel. :-)
CC and similar is probably something we cannot solve ourselves and
should leave it application to deal with IMO.
The real problem is with simulating the bidirectional communication
for patterns like req/rep or survey.
One option would be to follow BSD sockets semantics and treat
nn_connect as "set remote address" and nn_bind as "set local address".
(Of course, allowing for multiple remote and/or local addresses,
SP-style.)
That way, user attempting to use, say, a req/rep protocol over UDP
would be expected to set both local and remote addresses. If he misses
one of those, tough luck, the protocol won't work. Also, if he
misconfigures it, it may happen that reply is sent to a remote
endpoint that was not connected beforehand. That could be though of as
a feature though, rather than a bug.
Thoughts?
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTM9iAAAoJENTpVjxCNN9YzzcH/2GbBwdBHmOyZJIi0vCT9b9o
EdOAo16ALbEmpTBrnVxU9M5JAqN2z+XkQcCcKt3ZADwhXgNdzDAh+GGSOmcyM6v/
N+J1pywDMglbjNcYrACIROXTZAqJQ7pcoziTr7FO/GSEuIxO7DjFRqvyEicYQAJg
AQDG8EBvZOtKlYs+q+QyNlbGiPsmw1y2cYSootCIMLZbpzej5/gs/dKlmwZ7P3jg
egVs2CUrhIa9c2dJpHrcHGea6f8b8WUZcTiusGKAM2490GtlKwCeQ86mafRtYCwV
RZZhF68yiBfd6yOfmVUIBMEQnc0Y3JD7pqNG42Yv2MAooKdbJAXUa+dMQITiFhU=
=Fk3K
-----END PGP SIGNATURE-----
Other related posts:
