[PL #2268] static context ID numbers
Marc E. Fiuczynski via RT
devel at planet-lab.org
Thu Nov 4 07:08:45 EST 2004
Email Recipients (see http://www.planet-lab.org/Support)
Requestor: mlhuang at cs.princeton.edu
Ticket Ccs: mlhuang at cs.princeton.edu, smuir at cs.princeton.edu
What is the status of this dicussion? My take is that while we could
easily assign static context ids by putting the logic into PLC, it would
unnecessarily centralize the solution. That said, I don't see anyone
bothering to develop any alternative, decentralized solution that other
software developers could use.
There are two approaches:
1) we do nothing
2) we develop a centralized solution with the caveat that we may stop
support for this solution at any point in time.
Approach (1) forces developers to come up with a new (ideally better and
decentralized) means of identifying another slice, while with (2) we are
not bound to maintain the solution indefinitely.
At this stage I am not sure what the best approach is.
> [justin at cs.arizona.edu - Mon Oct 04 20:39:32 2004]:
> > > Slices should be assigned static context ID numbers that are the
> > > all nodes.
> >why should we do this? while it's clearly possible today it may end
> >placing a significant burden in a less centralised planetlab world.
> It would help our service environment (Stork) to know who it is
> talking to
> with on connections. I agree that the context numbers need not be
> identical across nodes, but there needs to be something identical we
> identify slices by.
> >using slice IDs will work okay until a) they overflow 16 bits, and b)
> >slice IDs are no longer just numbers e.g., in a federated world.
> Sure... names, numbers, whatever... As long as it is unique it will
> I can imagine (perhaps incorrectly) that many other PL users would
> like to
> be able to write code that only opens a socket with their slice on a
> node. That is, I could check in my code that I'm actually talking to
> slice and not either (a) another program that happens to use the same
> or (b) an imposter program for those of us who need authentication but
> >put another way, i'm not sure the minimal value of doing this (which
> >haven't heard anyone crying out for, nor even the similar 'slicename
> >ID' mapping sensor) outweights the potential burden imposed by the
> >consistency requirement.
> Like I said, having sliceID specifically be consistent is not that
> (at least to us) but what is wrong with making the sliceID that unique
> In our case we primarily want something we can map to a slicename
> Proper uses slicenames).
> Express yourself instantly with MSN Messenger! Download today - it's
More information about the Devel-community