More ProxyComm issues: VLS-free operation?

Bill Frantz frantz@communities.com
Mon, 28 Dec 1998 11:18:02 -0800


At 12:51 AM 12/26/98 -0800, Eric Messick wrote:
>This stuff looks like it falls in my department.  I haven't looked at
>the code in it's current form, but I can speak from the past.  Sounds
>like there haven't been any substantial changes.

[+] If it ain't broke, don't "fix" it.  There should be no substantial
changes in the vls logic.

>In message <4.1.19981225114040.009d9960@ricochet.net>, "Mark S. Miller"
<markm@caplet.com> wrote:
>>2) Tracing a warning if there's no search path would be fine, but tracing
an 
>>error or throwing an exception seems excessive, as this is reasonable for 
>>completely vls-free operation, which we should allow.
>
>The issue here is not quite vls or no vls.  As explained above, you
>can have a valid search path with no vls.  Creating a
>ConnectionsManager (or Registrar) implies that you want to be
>contactable.  If you don't have a search path, you can't be contacted,
>so the ConnectionsManager will be inneffectual, hence the error at
>its creation.

[-] A warning message would support "originate only" vats.  These are vats
that can make outbound connections, but do not receive incoming
connections.  (They do not export sturdy Refs.  Suspend/resume is handled
by the code which adds the current ip:port to the search path.  (See below.)

>>     ******************  The Big One **********************
>>
>>4) Most interestingly, the code that's apparently trying to enable vls-free 
>>operation is this in ConnectionManager:
>>
>>    /*package*/ void listingAt(String listenAddress) {
>>        myListenAddress = listenAddress;
>>        if (null != listenAddress) {
>>            myLocalFlattenedSearchPath = listenAddress + ";" 
>>                    + myLocalFlattenedSearchPath;
>>        }
>>    }
>>
>>which is called by the DataCommThunk, which is called by the ListenThread.  
>>It is correctly adding the TCP/IP address of this vat to this vat's search 
>>path, as known by the ConnectionsManager.  This would be fine if the search 
>>path were maintained in one place and shared.  Unfortunately, there's
also a 
>>search path stored (at least) in the Registrar and the ProxyManager, and 
>>neither of these are updated.  Should these instead obtain the search path 
>>from the DataConnection?  Should there be an mutable search-path object 
>>that (at least) all three of these share, so they all see the update?
>
>There is some confusion here.  I think what's going on is that the
>search path is used for two different (related) things.  First, it
>goes into SturdyRef's.  Second, it's handed around as part of a three
>party handoff.  In the first case, placing the actual listenAddress in
>the search path doesn't make any sence.  In the second case it does.

[#] Actually, this code is attempting to optimize suspend/resume.  The
Microcosm experience taught me that good suspend/resume is important
because of the cost of connections.  (The figure 500K/connection sticks in
my mind, but more recent measures show it at about 100K/connection.)  Since
the search path is used by resume, and resume can be initiated by either
end (even in the originate only vat case), the vats add their current
listen address to search path they advertise.

20-20 hindsight indicates that it is more useful for the remote end of the
connection to determine the IP address than the local end.  Having the
remote end determine address transparently supports certain firewall
configurations and IP address renumbering.  Sidney Markowitz' ISDN router
was supported by having the vls register the IP number it was talking to,
rather than the IP the vat thought it was sending from.