search

real-logic / aeron

Efficient reliable UDP unicast, UDP multicast, and IPC message transport
Apache License 2.0
7.39k stars 888 forks source link

Unexpected duplicate session ID. #662

Closed kpdsquare closed 5 years ago

kpdsquare commented 5 years ago

Hi,

I think this might be down to my misunderstanding, but after reading the protocol specification and reading this comment https://github.com/real-logic/aeron/issues/537#issuecomment-411745995, I don't understand why I'm seeing a duplicate session ID in the following scenario.

Using Aeron 1.15.2, I have a gateway application on host_1 and two client applications on host_2. Client applications, client_app_1 and client_app_2, both share the same media driver on host_2. Both client applications need to setup a publication to the gateway. Each client creates the publication with channel aeron:udp?endpoint=10.50.30.10:50061 and stream ID -1. What I found was that the two session IDs created for the publications on client_app_1 and client_app_2 are the same. I was expecting the session IDs to be unique. Am I mistaken and not understanding the protocol specification correctly?

I was hoping to use the session ID in a protocol to create necessary request/response publications and subscriptions.

tmontgomery commented 5 years ago

If you use a normal Publication on the same media driver, then 2 clients will share that Publication *(same channel and streamId). For the same media driver, try using ExclusivePublication to avoid sharing.

Note: session IDs are not guaranteed unique. They are only 32-bits. So, they serve your purpose very poorly. If/when they collide, the additional term id serves to have one session win over another on the receiver. You will want to have the server (in a request/response scenario) assign a unique ID instead.

kpdsquare commented 5 years ago

Ah yes, I forgot about the ExclusivePublication. I actually started building the unique ID creation on the server side and independent of the Aeron protocol specification after coming across this issue. It appeared to be a more robust solution. I was trying to take an unnecessary shortcut. Thanks for clarity.

kpdsquare commented 5 years ago

Sorry to reopen this issue, but I was just considering another related scenario. If I have a server on host_1, and a two clients on two different hosts, host_2 and host_3, the server and client applications would need their own media drivers on each host. Am I right to say, it's possible that the publications created on the client applications could have the same session ID even if I use ExclusivePublication?

tmontgomery commented 5 years ago

Yes. It is possible. But very unlikely. However, clashing session Ids (which is, again, very unlikely - 1 in 2^32 roughly) resolve via term ID. One will be ignored over the other. If perhaps termIds are within 1 of each, you should play the lottery. That is 64 bits of entropy (2^64) you just aligned.

Note: many protocols use these techniques. Very little is totally guaranteed.

kpdsquare commented 5 years ago

Understood. So, from what I understand and looking at the code base, in the highly unlikely case that there is a clashing session ID, the AvailableImageHandler on the server side would only be called once when there is a duplicate session ID. Is that correct?

mjpt777 commented 5 years ago

A duplicate session would not generate a new image and thus the handler will not be called.

kpdsquare commented 5 years ago

Thanks for confirming.