Re: [PATCH] New ORB_init option "ORBNetID=<string>"

[Ilguiz Latypov <ilatypov diskstream com>]

On Wed, Jul 27, 2005 at 03:55:21PM +0200, Jules Colding wrote:
> I agree. Would the right cure be to change get_netid() to
> unconditionally return an IP address and simply remove the ORBNetID
> option entirely? 

Removing a name-based identification can complicate the client's
access when the latter is behind a router (router1 in the diagram
1 below).  

Without the name-based access, the only way to enable connections
from the client would be adding a route record on the router1,
provided that the server's internal address SERVER(LAN2) doesn't
collide with the client's LAN1.

               Diagram 1.  Numeric addressing.

  client - LAN1 - router1 - internet - router2 - LAN2 - server

 "Obtain IOR of server"

         ->

         <- IOR:
            "My address
            is SERVER(LAN2)"

  "Connect to
   address SERVER(LAN2)"

  [Case 1. LAN2 != LAN1.
  Default route points
  to ROUTER1(LAN1).

  Case 2. LAN2 == LAN1,
  SERVER(LAN2) not in
  { workstations(LAN1) }.
  An extra record has to
  exist on the client
  that directs packets
  sent to SERVER(LAN2)
  via ROUTER1(LAN1).

  Case 3. LAN2 == LAN1,
  SERVER(LAN2) in
  { workstations(LAN1) }.
  The extra route record 
  will prevent the client
  from communicating with
  the collided workstation
  in LAN1].


  "Route to ROUTER1(LAN1)".

              -> 
                   Router1 finds
                   a NAT record
                   for SERVER(LAN2).

                   "Rewrite the destination to
                   ROUTER2, rewrite and record 
                   the source port in the NAT 
                   table.  Send the packet".

                          ->

The routing technique is limited to the cases when the LAN1 and
LAN2 network numbers are different.  Otherwise, the extra route
record would have to be added to each client, provided that the
server's LAN2 address is different from any address in LAN1.

With the name option, it would be sufficient to set up a name
record available to all clients in LAN1 pointing to the remote
server's router2.  Thanks to the short name option suggested by
Jules, the name resolution mechanism on the client will not be
limited by DNS, but may include NetBIOS, mDNS and SLP.  See the
diagram 2.

             Diagram 2.  Name-based addressing.

  client - LAN1 - router1 - internet - router2 - LAN2 - server

  "get the 
   address of 
   server"
           ->
           DNS, NetBIOS,
           mDNS, SLP...

            <-
          "server's
          address is
          ROUTER2".


  "Connect to
  address ROUTER2".


  The default route
  for non-private
  addresses points
  to ROUTER1(LAN1).

  "Route to ROUTER1(LAN1)".

              -> 

                   "Rewrite and record the source
                   port in the NAT table.
                   Send the packet".

                         ->

As far as I understand, Tom pointed out that there are inconsistencies 

  a) between the address of the non-loopback interface and the address 
     of the host name and

  b) between the name of the non-loopback interface and the host
     name.

I am asking if it is possible to avoid these inconsistencies by
providing only the host's name to the clients.  One could leave
the investigation of non-loopback interfaces to the configuration
mode of numeric addressing.

-- 
Ilguiz Latypov

programmer at DiskStream
Waterloo, Ontario, Canada