ken@gvax.cs.cornell.edu (Ken Birman) (07/28/89)
.SH NAME isis_connect \- Make a TCP steam connection to another ISIS process .SH SYNOPSIS .B #include "isis.h" .PP .B fdes = isis_connect (who_p) .RS .B int fdes; .br .B address who_p; .RE .SH DESCRIPTION isis_connect provides a way for a pair of cooperating processes to construct a high bandwidth channel for stream or message communication. Both processes call isis_connect, each specifying the address of the other. The calls block until a rendezvous occurs, at which time a TCP connection is made, an exchange of data occurs to verify correct functioning of the channel (this also ensures that both calls return more or less at the same time), and the file descriptors created are returned to the callers. The file descriptors obtained from isis_connect can be used within calls to msg_read and msg_write, or directly in calls to read(3) and write(3). Performance will generally be substantially better than for transmissions that pass through ISIS. The overhead of making a channel in this way is high. Use of a dedicated channel is consequently recommended only in cases where the channel will subsequently be used over a long period of time or for large volumes of data. The routines isis_input and isis_input_sig can be used to monitor such a channel for data if necessary. .SH DIAGNOSTICS If an error occurs, -1 is returned and the UNIX error code (in the global errno variable) may be examined by the caller or printed using `perror'. .SH NOTE Calls to isis_connect will block until the connection is established or the remote process fails. In the latter case, ECONNABORTED is returned. .SH "SEE ALSO" isis_input(3), ISIS(3)
jlevy@arisia.Xerox.COM (Jacob Levy) (07/28/89)
Do you have any delivery guarantees on the messages going through this dedicated channel (or only those (non)guarantees provided by TCP)? If there are delivery guarantees which mimick, say, the ordering semantics of cbcast, what is the relative merit of using a dedicated channel over using cbcast with a process group containing only the destination process? The following comments assume that strict adherence to the semantics of TPC transport are imposed by the referenced suggestion, with no additional ordering guarantees. Specifically, assume that we have three processs, A, B and C. A and C both send to B via a dedicated channel, but A and C communicate via some ISIS primitive. Clearly, it is possible for A to send to C, then to B via the dedicated channel. C reacts to A's message by sending to B on its dedicated channel. If there are no ordering constraints, B may see C's message before A's. Thus, having included a mechanism for communication which fails to obey ISIS conventions but which can be used in conjunction with ISIS (e.g. it can be monitored with isis_input), you've opened up a whole can of worms. In summary, the suggestion Ken made, if my assumptions about lack of ordering guarantees are correct, 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