Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!ken From: ken@gvax.cs.cornell.edu (Ken Birman) Newsgroups: comp.sys.isis Subject: Re: ISIS suggestions Message-ID: <33006@cornell.UUCP> Date: 9 Oct 89 13:22:08 GMT References: <32799@cornell.UUCP> <409@belltec.UUCP> Sender: nobody@cornell.UUCP Reply-To: ken@gvax.cs.cornell.edu (Ken Birman) Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 26 In article <409@belltec.UUCP> lance@belltec.UUCP (Lance Norskog) writes: > About using shared memory: some academic group (I'm soooo precise) is working > on a network card that just implements a shared memory address space... > ... This makes shared memory-based protocols more interesting... I am familiar with two such efforts, both at CMU -- one is Kung's Nectar project; I don't recall the name of the other. I agree, these could lead to very fast memory-based protocols. I think I've mentioned that in the BYPASS mode ISIS allows the user to define new transport protocols -- ways of getting a message from its source to a set of destinations in FIFO order (ISIS handles failure detection so this is pretty easy). Our plan is that if someone comes out with some spiffy new network interface, such as you describe, we can just code a "transport protocol" for it and plug it into ISIS this way. The idea is that instead of having to recode big parts of our system for each new networking architecture or device, we can retain as much code as possible. However, the BYPASS stuff only applies to CBCAST messages sent to a whole group by one of its members or to point-to-point messages sent from one group member to another. We design most of our code to send primarily these kinds of broadcasts. You may want to keep this in mind if you are building ISIS applications. Ken Birman