[nanomsg] Re: understanding of BUS protocol
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Thu, 10 Apr 2014 01:47:20 -0700
In the everyone to everyone case what keeps the packets from getting stuck in a
loop? Any cycle would be tragic right? I think a TTL is required.
I'm not sure I like exposing pipe ids to applications. It's needed in your
implementation because the forwarding is done by the app rather than by the
library. In my implementation the forwarding is handled without the apps
awareness.
I think non star graphs will work in my case just as well as yours. I think
both will suffer catastrophically in a true mesh or any other arrangement with
cycles in it. The only way I know to fix that is to break the cycle with logic
at the application. That can be done with a device using two sockets
explicitly. You can do that today with either implementation.
It is impossible to filter at the app in your library using only a single
socket as the pipe pointers will be meaningless to the app.
So the pipe ids just become a token you have to pass to keep state between the
time you receive a message and the time you resend it. I don't have that
problem as the context is handled without any interference by the app.
Essentially my approach automates the bus logic. The only messages a non device
app ever needs to explicitly send are those it is originating.
Sent from my iPhone
> On Apr 10, 2014, at 1:17 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/04/14 10:05, Garrett D'Amore wrote:
>
>>> I understand that is why you were using the pipe in the header.
>>> My implementation achieves the same thing, by moving this
>>> “device” functionality into the protocol itself. In other words,
>>> anytime someone in the bus gets a message, he sends it to
>>> everyone *except* the pipe he got it from. I do this
>>> immediately, without needing to push it up to the application
>>> (the device in this case) to do the forwarding.
>>
>>> What this means is that each “bus” acts as a local star (usually
>>> — although I guess you could have a client dial multiple
>>> different servers and have it act as a point.) I am assuming
>>> that we are not a fully mesh connected network, but more like a
>>> star.
>
> Unfortunately, the local network is often not a star but rather a mesh.
>
> There are two use cases for that:
>
> 1. Multicast protocols, i.e. there's no central server, packets are
> forwarded to individual boxes on the LAN by the network itself.
>
> 2. Eliminating the SPoF created by the device by connecting individual
> applications directly (everyone-to-everyone) instead of via a device.
>
>
>>> We can connect multiple stars together with devices. But if
>>> there is a loop in the network, it will not be possible to
>>> prevent message duplication/amplification with just the sender
>>> ID. You’d really need to introduce a TTL, along the lines of IP
>>> networking. I don’t think we want to get into that.
>>> Applications should just take care not to create loops.
>
> I was thinking about TTL and loop detection, but I was not sure it's
> appropriate or even needed. So I let it be in the end.
>
> Martin
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTRlOwAAoJENTpVjxCNN9Y/lMIAKyWPdO64r0lemoS6IEGl3C1
> 0mBzCgfdJg7pdpWtl6z78FR5/b1DT/h7rRBMo/NoEijWP2IqH4DmOglqQlKfUQZX
> 9YrPLuGTss2qKNdv/dy5mUdWQFJoAdPZFxV2UVV6NguXOVkMEyMFux11PtxN1bB2
> LIoLAWgmBjbBz53u9GT0LByuDmbIkcsvbiqG3hgfQBbE+0EzQgMCuHHpGrPvFc//
> jKLgseTdTIXO8X4qk8VTeiOSpH3UaCMvgDui8mw1/WK9PMgPLKbUZOQrqYDwAa2E
> 1CfXGzSlec6aycnD/N4x+ZPahKsEX3h43J0Mu+A4JK45wuoiN4Y2A0FPWALKnQo=
> =WyMd
> -----END PGP SIGNATURE-----
>
Other related posts:
