[OpenAFS-devel] NAT Patch and bugfix for vlserver

[Jeffrey Hutzelman]

On Wednesday, April 26, 2006 05:48:57 PM +0200 Tommie Gannert 
<d00-tga@d.kth.se> wrote:

> Ok, does this have to do with the three variants of
>
>   vlentry_to_{,u,n}vldbentry()
>
> in vlprocs.c? But how do i get 'vos listvldb' to list more than one
> address, for instance?

Yes, and more specifically, the difference between the 
VL_GetEntryByName{O,N,U} RPC's.  Applications which need to know all of the 
relevant server addresses should use VL_GetEntryByNameU, which identifies 
servers by UUID, followed by VL_GetAddrsU, which lets you look up a server 
by UUID and get information like addresses.  Eventually, the interface for 
finding IPv6 addresses or servers on non-default ports will involve the 
same approach, but with a replacement for VL_GetAddrsU which returns 
additional server information.

Unfortunately, you can't get 'vos listvldb' to directly show you server 
UUID's or more than one address per server.  However, any given address can 
only be assigned to one server, so you can take the server names or 
addresses reported by 'vos listvldb' and feed them to 'vos listaddrs' to 
find out the UUID and/or other addresses assigned to that server.

> If I remember correctly, buserver sends an address. One address. It
> seems like a small performance gain, though. butc could be doing the
> VLDB lookups in all passes.

I suspect that's not so much an attempt at improving performance as an 
indication of how old the bu subsystem is and how little attention it got.

> I'm not sure if the clients are better off making the decision,
> though. If they are behind NAT with the same subnet as the server,
> things will get messy. The idea of using common address bits means
> it will resort to global address space pretty easily. However, it's
> a hack, yes.

Well, it's got to resort to a global address if it's not on the same 
private network as the server.  However, since the vlserver never gets to 
see the client's private address, it's not really in a position to make the 
right decision.


> Actually it affects any command line parameter which is strcmp-parsed
> after '-rxmaxmtu' (which was placed in the middle of the list). It
> says
>
>   if (!strcmp(argv[i], "-rxmaxmtu")) ...

Sure.  Which means that clause only triggers if argv[i] is "-rxmaxmtu".  If 
that string never appears on the command line, it's highly unlikely that 
condition will ever be true.

In any event, this option is relatively new (it wasn't in 1.4.0), so I 
doubt many people have noticed yet.