Question about replacement for deprecated nng_pair1_open_poly

[drbitboy]

Hi All,

I am new to NNG, and don't see the forest yet; how does NNG handle multiple independent peer-to-peer "pair" connections to a single peer listener (but not a server)?

Thanks,

Brian T. Carcich

Background

I read this about nng_pair1_open_poly being deprecated. The alternative suggested there is the mesh or survey mode/pattern, but I believe those do not seem fit my use case.

My use case has many peers connected long-term to a listener peer over a single socket (tcp://hostname:port), with each peer message being handled uniquely and asynchronously by the listener peer (actually, all of the peers are identical, but one will "listen" and all others will "dial"). Specifically,

• messages can be issued by either side of a connection at any time (not survey i.e. not poly-req/rep)
• most messages do not require a reply/response on the same connection,
  • although some messages may trigger subsequent messages to a subset of connected peers.
    • subset means not a broadcast i.e. not a mesh routing pattern (not mesh)

Something that is similar to my use case is pub/sub, with the exception that the dialing peers generate the published content, so each connection is bi-directional. I assume that pub/sub does not handle this, but I would be happy to be wrong about that.

I am on the way to a working prototype using a modified version of the pair0 example I found, using nng_pair1_open_poly (still need to convert it to aio), but I would prefer not to do this with a deprecated pattern likely to disappear in future.

[gdamore]

I don't think you should worry about nng_pair1_open_poly() too much -- as long as you are willing to live with an NNG-only solution. Pair1 Poly won't be implemented in mangos. But it won't be removed until I have a replacement for it.

Your specific use case is arbitrary unicast messages to different participants. Pair1Poly has a "pipe id" for this, and you can use it for that.

Probably a future mesh pattern would build upon the API logic in pair1, but most importantly we need to change the wire protocol because to properly do this we need to create peer IDs and a stack backtrace. I've not yet figured out the best way to do this. It's simple until you start considering nng_device() style proxies, then you have problems because you won't necessarily known about everyone on the mesh- and you have to have a way to refer to them, as well as discover them. This could lead to a lot of traffic, so it won't be good very large scale networks.

But in the meantime, if pair1 poly is doing the job for you, don't worry about it. As I said, I won't remove it until I have a suitable replacement -- and there will be a major release boundary before I take it away.

[drbitboy]

Thank you.