[torquedev] [patch] bind to ip on multihomed pbs_servers
garrick at usc.edu
Fri Feb 8 13:01:57 MST 2008
On Fri, Feb 08, 2008 at 09:39:46AM +0100, Adrian Knoth alleged:
> On Fri, Feb 08, 2008 at 09:11:54AM +0100, Henning Glawe wrote:
> > > I also have a patch, but mine is more invasive, modifying the
> > > svr_connect() and client_to_svr() functions by adding the ip address
> > > to bind to as a passed argument. Your patch is much simpler, so I
> > > hope it makes it in.
> > well, my patch is more a proof-of-concept, as it is an unclean solution
> > communicating the IP to the relevant functions by a global variable...
> I'd like to point out that the whole IP stuff in Torque is totally
> behind state of the art.
> To sum things up, an IP address is nowadays not represented by
> uint32_t, but struct sockaddr_storage.
> Many functions in Torque have these obsolete assumptions, and AFAIK,
> it's PITA to port it to IPv6.
> One former attempt has failed, and I guess my student (mabi) has either
> given up or is stuck somewhere. Matti, could you elaborate on this?
> No, don't use an IP address as a 32bit key value in a binary tree, this
> is incompatible with 128bit IPv6 addresses.
> Lots more. If you ever plan to support IPv6, don't write any new IPv4
> code, but clean up the old one. It's a design goal. API changes are the
> least important part of it. It's pretty much a whole new version, major
> release, whatever you want to call it.
> Do it now or do it never, you cannot prolong the 80th's way of coding ad
No disagreements here.
The sorry state of addressing handling *and* name resolution needs to be fixed.
I don't know that we want to accept any more changes to networking stuff until
we do this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torquedev/attachments/20080208/c3c23a9b/attachment.bin
More information about the torquedev