Generating new islandID.

[Separate FYI: The Router and the Continuity server at croquetcollaborative.org
have been updated to the current versions of everything in the Monticello
repository ( http://hedgehog.software.umn.edu:8888) as of the SDK 1.0 release
date. This is actually a little ahead of the SDK distribution, so if you start
with that, you need to update a few of the packages. I think there's three that
changed.]

Each harness maintains a list of islands by name and by islandID. I think of
islandID as being authoritative, and name as being symbolic (with the
possibility of application-specific indirection, although I don't think there's
anything in the code that leverages such indirection).

The stable pointer into an island -- which can be stored in other islands (e.g.,
in portals) -- is a Postcard.  There is a pattern that appears in a couple of
places in the code where:
   #findIslandByPostcard: looks up an already processed island by name and ID, else
   #findContactByPostcard: -- which might be better named
findIslandByPostcardViaContact:.

Given this framework, there are a couple of different approaches that can be
taken. See http://opencroquet.org/index.php/WAN/LAN%2C_Connecting_and_Discovery

    For example, you could hardcode the router address:port into the Postcard
and hardcode the join process in #findContactByPostcard:.  (See the demos that
use CroquetHarnessWithMenu.)

    The KAT delegates to to a Contact to resolve and join with the router for
each specific name/ID. (The Contact then delegates to a ConnectionStrategy to
manage the join process, including reconnection as necessary.)

    The other demos use a strategy midway between these two.

For those demos that use Contacts, how are the Contacts created? There's a map
of name/ID to Contact called a ContactPoint. (I don't know the origin of the
name. I think of it as a "DNS"-like thing, or "Contact discovery map".) The
middle-ground demos populate the ContactPoint automatically by having "Masters"
broadcast their worlds on the LAN.

The KAT just hardcodes a fixed set of known worlds: each Harness explicitly
creates a set of Contacts to populate the ContactPoint in
KStandardHarness>>setupUser:password:entry:address:port:. The next step for KAT
development is to instead start with an empty ContactPoint and have it consult a
service whenever there is a request for an unknown ID.

Note that the name/ID managed by the ContactPoint has to match that created by
the Router. (In order to not use lots of different IP ports, communications on
multiple Routers are multiplexed through an object called a Dispatcher. The
Dispatcher has a means of dynamically creating new Routers (for the requested
ID), or rejecting a request to connect to a non-existent Router ID.)  The KAT
creates a hardcoded set of Routers with the known set of IDs.  In the current
KAT code, this known set of Worlds is given by KCroquetParticipant worlds (a
class method). The ID for a given world is specified by the #islandID class
method for the class that represents that world (e.g., the subclasses of
BaseWorld). Notice that the values returned are not generated dynamically, but
are hardcoded:
   TObjectID readHexFrom: '1f2f349874e53ebe785f68158591e917'
This is because the value must match up between the router on one machine and
each participant on different machines.  You can generate a suitable new string
by print-it of TObject new, but then you paste that string into the above.

[The Dispatcher at www.croquetcollaborative.org:5910 does not dynamically create
new routers for any old ID you might specify. If you try this, it just logs the
attempt and disconnects you.  You could imagine some extension of the protocol
whereby a client could present some credentials to tell the Dispatcher to
operate a new Router as a service. But the Collaborative has no plans to do
this. (We don't have the bandwidth.) As I said, I would like to have the KAT
have an option for any user to create their own Router on their own machine and
advertise it via a service that others can use to populate their ContactPoint,
but you'd still have to run your own Dispatcher/Router.]

Nikolay Suslov wrote:

> Dear Horward,
> It is ok or not?
> that when I try to change islandID in WisconsinWorld class to
> some other ID (for example: ^TObjectID new)
> KConnectionStrategy fails in getting the states:
> 4. authenticated
> 5. synced
> What is the logic in generating islandID's in WisconsinWorld and
> WinsconsinSDK is used (in Croquet 1.0)?
>
> Thanks,
> Nikolay

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
[hidden email]
office:+1-608-262-3724
mobile:+1-608-658-2419