Hi Michael-
Thanks for a brief description of your project.
Regarding routing, we do support IP encapsulation of STP -
when the upper layer protocol using STP uses INET addresses.
The various sequences defined for STP make it useful for
both high b/w and low latency scenarios - whether through
the kernel or from user space.
Of course, I'll need more details about your project to say
something more sensible, but this is what I can come up with
at the top of my head:
STP establishes connections from a NIC to NIC; and the address
space is the ports (in h/w or s/w) on the NIC. The higher layer
addressing (like INET) is dealt with by the upper layer protocol
e.g. we have an implementation that uses INET addressing on
STP; SCSI might want to use different addressing (don't know).
For your purpose - I could see your protocol being an
upper layer protocol on STP; you want to use something other
than INET addresses, and that's possible. This will let you
leverage off the low latency, high b/w transport mechanism that
STP provides (on a variety of interfaces, hopefully :-)
Let me know if this makes sense. I'd be very interested in
discussing this in more detail with you.
thanks,
:a
>
> Hi Aman,
> in your original post there was some comment above collaborating with
> other projects which I like to see too.
> Recently, I have started writing a network protocol for linux but it is
> in its early stages ;-)
> I am interested in distributed computing, clusters, distributed
> operating systems, group communication, etc.
> Given that many users will want to put together linux clusters of some
> sort it is appropriate
> to provide the necessary mechanisms in the kernel to do this in a nice
> way. One way that is interesting
> to pursue is to add some mecahanisms for location transparency which are
> lacking in Unix. I have
> started to do this for Linux. The basic idea is simple and comes from
> the FLIP protocol of Amoeba.
> Replace IP network layer with another protocol which works without the
> upper layers knowing
> which machine a process is on. Of course, one wants to have the nice
> features which you have seen (?) for
> STP as well -- large bandwidth and low latency. I have added code to
> Linux 2.3.44 which adds
> a random address to every process created called the flip address (64
> bits). I have departed from the
> original protocol when it comes to routing though. My guess is that
> every Linux machine in a cluster
> will have an IP stack anyway and so why not use it for routing. Also, I
> propose that the routing table
> for flip addresses on a machine only contains nonlocal addresses. The
> process table itself with suitable
> hashing should be enough for flip to work on a single machine. This
> again departs from the original.
> Upper protocol layers needn't care about location. For a tightly coupled
> cluster this should be efficient too
> but the basic abstraction makes building distributed services simpler I
> am guessing though since I haven't
> actually done it. Many of the features I wanted for this FLIP/Linux
> protocol apart from addressing appear
> in STP. I wonder whether the too can be blended to give a rather nice
> hybrid for clusters.
>
> Yours,
> Mike
|