[nanomsg] Re: semantic of PAIR sockets...?

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx, Martin Sustrik <sustrik@xxxxxxxxxx>
  • Date: Wed, 26 Mar 2014 00:24:53 -0700

Thanks for the confirmation of my understanding.  I’ve implemented (untested so 
far) that in my Go version.  I can’t see any possible application that would 
*prefer* these semantics to Req/Rep, (or alternatively Pub/Sub, if they don’t 
really *care* about delivery), but — what do I know? :-)

I did a bit more coding this evening, cleaning up the interfaces to make them 
much friendlier for people either reading the code, documentation, or wanting 
to implement their own Protocol or Transport modules.  Its still not perfect, 
but I think the refactoring work I did will really help — and before the code 
got too big.  Right now its just over 4kLOC, so its easy to make some pretty 
sweeping changes.  (And the nice test suite and static compilation makes me 
feel very confident in those changes, unlike some other “modern” languages I 
could name — *cough* Python! :-)

-- 
Garrett D'Amore
Sent with Airmail

On March 25, 2014 at 11:24:06 PM, Martin Sustrik (sustrik@xxxxxxxxxx) wrote:

-----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: