[Spread-users] Multipath Spread #2

[Jonathan Stanton]

On Mon, Oct 22, 2001 at 01:46:52PM +0200, Marc Zyngier wrote:
> >>>>> "JS" == Jonathan Stanton <jonathan at cnds.jhu.edu> writes:
> 
> Hi Jonathan,
> 
> We haven't tested multicast yet. This will at least need one send
> socket per network, bound to the right interface, instead of a global
> send socket. This is the next (planned) step...

OK.

> Nice idea. Doesn't work on Windows (on W2K, bind fails on a non-local
> address), but we can work around this, though.

You said earlier that windows 2k was the one that just worked with the
regular unicast bind right? So we can conditionally do the bcast bind if we
are not on windows and just do a unicast bind on windows.

> JS> You added or changed a number of uses of IP macros to inet_ntoa. I
> JS> think this is not the right direction for a few reasons. The
> JS> reason we do not use inet_ntoa() in Alarms or other places is
> JS> because it uses a static buffer to store the returned string, so
> JS> if you use it multiple times in one alarm, then all of the printed
> JS> values are the same and equal whoever was last. So even though
> JS> your uses of it are only a single use per Alarm, it is easy to
> JS> forget the problem and someone later adds another IP address to be
> JS> printed and then you do not get correct values. So it always
> JS> seemed too dangerous to use this way. I definitely think there
> JS> probably is a better way then the IP1 macros, but I don't think
> JS> inet_ntoa is the way.
> 
> Fair enough. Part of this was because of the int/in_addr switch (see
> below).
> 
> JS> Why did you change the interface to DL_send to use in_addr instead
> JS> of directly passing the address? This also requires more includes
> JS> (data_link.h) and a more complex interface for apps using
> JS> data_link (more then spread use it). I know that using in_addr is
> JS> more direct sockets programming, but part of the idea of the DL
> JS> layer was to expose a slightly simpler and abstracted interface
> JS> that did not reqiure using native sockets types.
> 
> If data_link was supposed to be transport agnostic, why using IP
> addresses at this level ? Or am I misunderstanding something ?

In its current version data_link is definitely not transport agnostic. It
works for UDP/IP only. I have thought about the switch to ipv6 and it will
require a bunch or interface changes and datastructure changes as the idea
that a host ip address is 4 bytes is fairly well entrenched. 

What it is is 'host platform agnostic' for UDP/IP. So we can write
applications that use udp sockets and do not have to have any special code
to be platform independent, all that is hidden in data_link.c

> 
> At least having a specific type for an address would be nice
> (net_addr_t, or anything like that). This would help a lot if someone
> wants to switch to another transport (say IPv6 for example).

See above.

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------