[nanomsg] Re: semantic of PAIR sockets...?
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 26 Mar 2014 07:23:56 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 26/03/14 05:31, Garrett D'Amore wrote:
> I want to make sure I understand the *intended* semantic of PAIR
> sockets.
PAIR sockets are meant as a means to implement the most trivial way of
scaling an applications: Split a monolithic HR & Accounting
application into standalone HR application and standalone Accounting
application. In other words, scale from 1 box to 2 boxes. No attempt
is made to scale to arbitrary number of machines.
> I’m *thinking* that the semantic is supposed to be that once a
> connection is established, all traffic is forcibly restricted to
> that connection. That is, that we discard inbound packets from any
> other accepted endpoint, and we also don’t send out any packets to
> any other endpoint, at least until the underlying file descriptor
> closes. We also close any other connections when they are
> attempted.
Yes. That's it.
> If the peer disconnects (or we disconnect due to error), then a
> new connection can be established. No attempt is made to validate
> that the new partner is the same as the old.
Yes. No check is made as it may be a new (re-started) instance of the
old application.
> Also it appears that we make a very concerted effort to avoid
> dropping messages due to back pressure. The message is queued
> (unless non-blocking mode is requested, which I’m not doing in Go,
> at least not yet), and held for ultimate delivery until the
> underlying pipe is connected.
Yes.
> What about messages pending when the disconnect occurs? Should we
> toss them? Hold for the reconnect?
>
> Its still not “guaranteed” delivery, since without any
> acknowledgement from the peer the best we can do is ensure that we
> got it down to the OS file descriptor. Once the OS accepts for
> delivery, we’re done with it.
Yes. It's not perfect. Given that such a trivial case of scaling means
that the connection have probably replaced some internal component
boundary, we should probably strive for ack-based ("next call to recv
means that the previous message was processed and can be acked"),
one-message-at-a-time kind of delivery.
> Actually with these limitations, I see little use for PAIR
> sockets.
Yes. If you leave them out, nobody will be really sad, I guess.
> But I want to make sure I’m implemented the same, expected
> semantics. I’m doing the above (sans non-blocking mode). At the
> moment, I’m preserving messages across a disconnect… that is if
> someone tries to send a message and I don’t have a connected peer,
> I’ll hold the message until one is connected. Then I’ll try to
> deliver it.
Sounds reasonable.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTMnJ8AAoJENTpVjxCNN9YgQEH/3EEikoUD4Nh44b4lTPppPYk
Ea3EWHTJ7UogjdJ0Hz4zNUDzJfA0RLttA4YBzaApoDr2L+MSITytrZKuod6EiErV
psBV4By6B4NBJm2KfSW0VmPSPni4QWDmrv689UnfzfRCeLp9jT+MYYeT7ZtarEI5
w/K6VYCldBsxkVVEUoLeRgld7nWGQaX5a7sq3blev1swEIO75BJRVImnIlI1G6O/
eOvDHuDZXsHXp8QmrDijOR8C0RlbZmsny+mzwu7JiJ2LL8tqKyHC/GsBTKj16r6V
Um1oScSt68zBfthnAdxwA4EQc0o1iPLIFxuofWDdcY9zvv9n0VmecCDbQ9i9PbI=
=dPx4
-----END PGP SIGNATURE-----
Other related posts:
