ken@gvax.cs.cornell.edu (Ken Birman) (07/28/89)
>> Do you have any delivery guarantees on the messages going through >> this dedicated channel .... >> ... In summary, if my assumptions about lack of ordering guarantees >> are correct, [this proposal] is NOT a solution to the efficiency >> problem encountered when you want to communicate with only one process >> instead of with a group. We need a mechanism whereby you can use the >> process group semantics (perhaps you may want to include some declaration >> about the location and cardinality of the process group when you create the >> group) but which will be as efficient as direct communication. The proposed >> solution achieves the desired efficiency but discards all that is >> desirable and nice about ISIS. >> --Jacob Good point, and I have to admit that I agree with you on this! These channels are nothing more than normal TCP channels, and unless you use ISIS broadcasts to communicate with processes and tell them when to look at the channels, you get no guarentees of virtual synchrony at all (if you DO look at channels only when told to do so, this issue doesn't arise). I tend to view isis_connect as a bit of a stop-gap solution. My problem is that if people send 80 or 100k messages through the current system, it tends to congest -- and in any case, performance is really not acceptable for such purposes. Lots of people seem to be doing this, and I needed to put something out there in the short term to make life a little easier on them. The long-term solution will be to use the "bypass" broadcast mechanisms, which are still in a debugging/tuning stage here at Cornell. Under this interface, you can cbcast (not abcast/gbcast!) even very large messages directly to one or more destinations, and performance will meet or exceed that of a TCP channel. But, the bypass stuff is tricky and until it really works and we have the paper on it written, we needed some sort of interim patch. My suggestion is to code your algorithm so that it sends a message using ISIS that contains a "pointer" to a chunk of some amount of data to be received over some isis_connect TCP channel, more or less the way that DEMOS used to do its message passing. I'll mention this in the manual page on isis_connect. By the way, isis_connect isn't in the 1.2 distribution, but we'll be posting the source for it shortly and you can easily install it yourself if you like. Ken