On Thu, May 05, 2016 at 11:25:36AM -0400, Jan Harkes wrote:
> On Thu, May 05, 2016 at 01:13:53PM +0200, u-myfx_at_aetey.se wrote:
> > they verify that the other party belongs to the correct realm,
> > but this might happen to be a different server in the same realm. I guess
> > mixing the server id into the handshake would eliminate this uncertainty.
> 
> Eh? Server ids should not be exposed like that to begin with.
> 
> Aside from that a client isn't trying to connect to a server, it is
> trying to bind to a volume. If you get connected to the the wrong server
> (how in the world is that even a thing that would 'happen'?) it wouldn't
> be able to bind to the volume anyway and so the end result is the same
> without needing to put serverids in the handshake.
> 
> A client should have no need to know a server id, ever.

I guess you are thinking about things which are unrelated.

Think of a "server" as of an "RPC2 server" (f.i. update?),
the "server id" is the idea of the client about
"which service instance I am to talk to".

There are indeed situations where the outcome by intent does not depend
on which service instance a client is talking to (auth2). Then the
"server id" could be considered "empty".

This is not the case for other services. The server instances
generally are not equal e.g. for update the scm is special, for
resolution the coordinator is special.

I would not dare to analyze _all_ cases including possibly unknown future
ones and be sure that talking to a wrong instance never ever can lead
to a problem.

IOW as soon as we _assume_ that a client is talking to a certain service
instance, let us better _ensure_ that this is the case, not trust the ip.

This is a very basic thing to do and does not look expensive,
what would be the reason to oppose this?

Regards,
Rune