It is probably true that for a client-server protocol, the client does
not need to have a stack-ID.
From an architectural perspective, I tend to see that any machine may
sometimes be a server, and therefore I prefer to approach things by
giving every stack an ID.
Thank you,
Joel
Patrick Frejborg wrote:
Joel,
I think you are right here and I got it all wrong when claiming that
host-ID, hereafter stack-ID, should be coupled together with a
session-ID.
Now I agree that they should be separated - when separated only the
server need to have a stack-ID, the client doesn't need to have one.
Then we are close to a HTTP session token solution, aren't we?
http://en.wikipedia.org/wiki/Session_(computer_science)
-- patte
On Sat, Jul 4, 2009 at 5:36 AM, Joel M. Halpern<[email protected]> wrote:
The reason this (naming the set of locators that lead to the same entity)
leads to a stack ID (or node, host, something) is that I want that
collective property available before I start communicating.
Referrals are the easy case. I am trying to refer someone to a specific
entity. They do not have a session with that entity. So a session ID is
clearly totally useless for a referral.
I believe that similar constraints apply at the time of initial
communication establishment, in that there is a semantic difference between
using multiple locators for a target to establish communication and trying
to establish communicaiton with multiple "equivalent but distinct" targets.
I consider it helpful to udnerstand that distinction.
It seems clear to me that one of the important properties of a communication
session is the pair (or worse, if one likes multiparty sessions) of entities
that are talking. But session identification is much more specific than
just naming the communicating parties, or even the available interfaces. At
this stage of the game I do not care whether session IDs are minted using
the stack IDs, or minted out of whole cloth using bilateral state. Either
can work. I am not arguing that session IDs inherently require stack IDs.
They don't. I am arguing that stack IDs are useful separate from session
IDs.
Yours,
Joel
Christian Vogt wrote:
On Jul 1, 2009, Joel M. Halpern wrote:
It seems to me however that it is useful to be able to explicitly tell
which locators go with the same communicating entity, as distinct from
the larger set of locators which might go with the same service [...]
Joel -
Yes, we absolutely need this. But why does this imply the need for a
host or stack identifier? Session identifiers already map to the set of
locators that go to the same communicating entity. This is why we need
to distinguish them from service identifiers, which in turn may map to
locators of different communicating entities.
- Christian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
