Running Croquet examples across WAN(VLANS)

How to run Croquet applications across VLANS?
How do we setup router and participant script for running demo master and demo participant?
Both of the machines are behind firewalls. Is this an issue.
Do i need to set up port forwarding?
pls reply me.

Thanks
Kiran

The thing to understand, as a developer, is that there are a number  
of approaches for different purposes.  Some of this info is scattered  
around in the doc, the code, and dev mailing list.

0. The general underlying functionality in common to all the  
application is this:
  a) The Harness manages interactions with whatever islands you are  
participating in. This is a accomplished for each island by opening a  
TCP connection to the Router for that island. The router is the  
source of information about the island.  How the harness discovers  
the location of the Router varies. Also, how the initial island is  
created varies.
  b) When you start up the application, you are participating in some  
island.
  c) A Postcard is an object class in the system, that identifies an  
island and a particular object within that island.  Postcards are  
just data, not a live link/pointer.
  d) These windows that you see in the spaces can contain various  
things, and the window can be open or closed. The contents are only  
rendered when the window is open and within the view frustrum.
  e) Some Windows contain what we call a Portal, which in turn  
contains a Postcard.  A Portal renders as a live view from the  
perspective of the object specified by the Postcard.  So.... when you  
open a Window that contains a Portal, the Harness has to ensure that  
you have a connection to the Router for that island.

1. The CroquetMaster/Participant and BFDMaster/Participant are  
applications that are intended to illustrate collaboration on a LAN.
  a) Starting a XXXMaster creates not only a Harness, but also an  
application-specific number of Routers. These Routers are all  
channeled through a port-sharing mechanism called a Distributor  
(e.g., so that you don't have to a have a different port open for  
each Router running on your machine).  In addition, the XXXMaster  
goes ahead and creates (populates) an application-specific set of  
islands using a script, and each is connected to the appropriate Router.
  b) When you start an XXXParticipant on the same LAN, it broadcasts  
a request for any Distributors to identify themselves and any islands  
that they are routing for. The XXXParticipant has hardcoded the  
identification of the islands it is interested in. At startup (1b,  
above) and when you first render an open portal (1e, above), the  
XXXParticipant Harness consults the list of Routers that it obtained  
by broadcast, and forms a connection.

The requirement here is that the machines can broadcast to each other  
and that they know their own relative addresses.

2. All the demo applications written by the Minnesota team are  
intended to demonstrate connection on a WAN in principle. (Not  
necessarily the UI of how a production application might do it in  
practice.) These all start out like 2a, above, but do not broadcast  
anything on the WAN.  Instead, the user interfaces show it is  
possible to generate a textual serialization of a Postcard, with  
additional information about the address of the Router for the island  
you are currently in.  This is to be passed to other users by some  
other means (e.g., a separate text chat program) and entered into the  
other user's system. This creates a Window/Portal/Postcard  
combination like that described for 1, above.

The requirement here is that the machines know the address by which  
others can, in fact, reach them on the WAN.

3. You can start the Routers/Distributor completely separately. Look  
at the classes.  If you do this on a fixed IP address machine, then  
you can hardcode an application to look for worlds on the Distributor  
at that address. I think Andreas has posted some scripts for this,  
but I can't find the right version right now. (I'm headed out the  
door, and I had most of this already written up.) WiscWorld also  
worked this way, (based on the scripts,) and also made some  
modifications so that the original island definition can come from  
previously cached snapshot on disk.  A key thing to look at with the  
discovery are the Contact classes.  The WiscWorlds routers and  
continuity servers aren't running now, but the Monticello packages  
for the next version are at http://www.squeaksource.com/KidsFirst.html

The requirement here is that there be a stable well-known address by  
which the desired machines can reach the Distributor.


On Sep 1, 2006, at 1:27 AM, KiranMutt wrote: