Alright, let me go a little more specific. I am creating an application
for a large mesh network-like chat, I was planning on using this
disconnect functionality to ensure that there is a maximum number (set
by the user) of peers allowed to connect to the node, and any nodes
after that maximum would be automatically disconnected. It does not
really have to do with sending messages to specific peers so much as
disconnecting excess of peers beyond a certain point.
On Fri, Aug 11, 2017 at 04:45:24AM +0000, Garrett D'Amore wrote:
So I think the problem is that you may be misunderstanding how nanomsg is
meant to work.
Specifically, you are not *meant* to have to deal with or handle individual
TCP connections or sockets — nanomsg does that all under the hood for you.
All you have to do is pick the right pattern that fits your use case.
Nanomsg will automatically connect, and reconnect on failure, etc.
Bus is a pattern that is meant to be used with a fully connected mesh
(arguably it should have been called “mesh” instead of bus). In this
pattern, when you “send” a message, every connect peer on the bus receives
the message.
If you want to direct messages only to specific peer(s), then this is not
the pattern you are looking for.
Unfortunately, having good control over *which* peers you direct a message
to is something that the current nanomsg patterns don’t do well. This is
kind of unfortunate. You might want to have a look at my latest work
(which isn’t integrated into legacy nanomsg, but has only just integrated
into my “nng” product, which is API compatible with nanomsg but still
pretty raw) — specifically the PAIRv1 protocol, which has a “polyamorous”
mode where you can select which peer to send messages. There are some
unfortunate gaps still (knowing the pipe IDs of peers is difficult at
present because API support for getting pipe connection events is missing,
but I’ll fix that soon — you *can* learn about pipes on inbound messages
because the “pipe ID” is stashed into the message structure on recv, but
this requires remote peers to send you a message first. This can work well
for many connected peers.
Another approach you might want to do is to consider creating separate nng
sockets (each of which maps to a single peer, perhaps using PAIR or REQ/REP
or whatever), and managing the details of which peers you send manually in
your application. This can work well, but it won’t be as scalable as the
approach using the new PAIRv1 protocol that is in the works.
- Garrett
On Thu, Aug 10, 2017 at 9:07 PM Nicolás Ortega Froysa <
nortega@xxxxxxxxxxxxxxxxxxx> wrote:
I've been interested in using nanomsg for a personal project,
specifically with the BUS protocol. However I haven't found much on how
to manage individual connections with this (e.g. having a list of
connected peers or being able to disconnect specific peers). The only
possible way I can imagine doing this from what I've seen is for the
peer that initiates the connection (i.e. through `nn_connect()'). But
not so much for any process binding to a port. Perhaps it's simply that
I am not aware of how nanomsg works under the hood.
I am aware that with UNIX sockets when there is a new socket on a port
that you are listening to it gives you a new socket file descriptor for
that new connection, but I'm not completely sure how this crosses over
to nanomsg. Does anyone have good sample code demonstrating how this
would work?
Thanks.
--
Nicolás Ortega Froysa
https://themusicinnoise.net/
http://uk7ewohr7xpjuaca.onion/
Public PGP Key:
https://themusicinnoise.net/nortega@themusicinnoise.net_pub.asc
http://uk7ewohr7xpjuaca.onion/nortega@themusicinnoise.net_pub.asc
Attachment:
signature.asc
Description: PGP signature
