[Spread-users] Multipath Spread

[Yair Amir]

Dear Marc,

First, let me congratulate you on a pretty complicated modification
to Spread.

Although I am not Spread's chief architect anymore (Jonathan Stanton is 
currently doing this) let me through my 2 cents. 

In my opinion, such a capability is not merely a hack. It is much more
complicated, has a lot of ramifications on correctness (at least from first
glance) and therefore should be considered carefully, starting with what 
exactly the goal is. 

I understand what you are after in broad terms, but I don't understand 
the exact semantics of what you want to achieve.
Defining this exact semantics would be the first step, for me at least. I am 
not keen on looking at the detailed source code to extract this semantics
because this should be defined regardless of the code (and problems in
the current implementation should not affect the understanding of the
semantics).

So, can you define that? I am sure other people would also be interested in
commenting on this semantics and maybe together we could come up with something
that is general yet accurate.

	Cheers,

	:) Yair.	http://www.cs.jhu.edu/~yairamir

p.s.

I have some architectural comments: the data link layer (data_link.[ch]) is 
something that should be kept, in my opinion, as the lowest (and only) place where 
the real network is touched. This is very useful for maintaining portability. 
A multipath capability seems to me at first glance something that should be up, 
probably at the network level (network.[ch]), probably even integrated with it, 
as opposed to something which resides below the data link level. 

But I cannot say that for sure because I don't have the semantics yet. It might 
actually even go up to the protocol level instead for certain semantics I could think of
(for example - I assume you do not want to send every message on every possible path,
or do you? if not, do you use the default path and only in case of problems revert 
to the next path and so on? do you switch paths in agreement between the daemon? 
what information do you need in order to switch?)

Also, I like the way you specify the capability in the file. (maybe we can even
save the inner most {} ? )

Again, let me commend you and thank you for your efforts. Lets continue to investigate
this capability. (If you really need this to work quick-and-dirty and you have a 
small bug, we could invest a small amount of time looking into it with you
but that is very different from including it in our version of Spread.)

	:) Yair.


Marc Zyngier wrote:
> 
> Hello all,
> 
> We are currently considering using Spread in a high avaibility
> environment. One of our main requirements is the ability to handle
> multiple networks attached to each machine, and using those networks
> as a redundant link.
> 
> So we came, we saw, we hacked (famous last words...).
> 
> The basic idea is to describe the network topology in the
> configuration file :
> 
> Spread_Segment mp:4803
> {
>         192.168.110.255
>         {
>                 { foo   D 192.168.110.1 }
>                 { bar     192.168.110.2 }
>                 { fubar   192.168.110.3 }
>         }
>         192.168.111.255
>         {
>                 { foo     192.168.111.1 }
>                 { fubar   192.168.111.3 }
>         }
>         foo { C 127.0.0.1 }
> }
> 
> The 'mp:4803' token indicates that we are describing a "multipath"
> configuration. In this sample configuration, we have two networks
> (192.168.110.255 and 192.168.111.255). foo and fubar both have an
> interface on both networks. truc only belongs to the first. Moreover,
> foo will listen to clients on 127.0.0.1.
> 
> The patch changes the DL_send interface, so that we do not send a
> packet to an ip address, but to a proc. Another layer (multipath) is
> responsible for the conversion from proc to a list of addresses. Thus,
> it is quite invasive in both network.c and datalink.c. It changes the
> configuration parser quite a bit too...
> 
> Please note that this patch is a work in progress. It is not as nicely
> integrated as it should be, and probably introduces quite a lot of
> problems (we saw quite a few crashes with req_seq < Aru...). We'd like
> to get as much feedback as possible from Spread creators and users, so
> we can fix problems as fast as possible.
> 
> This patch is against 3.16.1beta1, and has been tested on Linux,
> Solaris and W2000.
> 
> Thanks a lot.
> 
> Marc Zyngier
> Evidian - SafeKit Project
> http://www.evidian.com
>