slaski@netwrx1.UUCP (Robert Slaski) (03/16/90)
I have some information concerning ISODE over TLI that may be of interest to those parties asking about ISODE and TLI. We recently completed an implementation of the ISODE 5.2 distribution over AT&T's StarGROUP OSI TP4 product on an AT&T 3B2/600 with System V Release 3.2 using the TLI. This implementation works co-resident with the Wollongong WIN/3B TCP/IP version 3.0 software which provides a BSD socket interface to the TLI. The implementation over TP4 does not use a socket interface, but goes directly to the TLI. So, what we have is a dual stack host providing FTAM over both the WIN TCP/IP via sockets-to-TLI-to-TCP and TLI-to-TP4. The following notes were compiled by the software engineer, Greg Lavender. The TLI-TP4 interface is called ts2attosi.c and is equivalent in functionality to the ts2sunlink.c and ts2bsd.c TP4 interface modules in the ISODE tsap directory, except that it uses the TLI instead of sockets. Modification were also made to tsaprespond.c, tsaplisten.c and tp4.h. The only annoyance in the implementation was the difference in the semantics of the socket accept call and the TLI t_accept call. Briefly, when a connection request comes into the tsap daemon, the socket accept is issued before forking and execing the responder so that the listen endpoint is cleared of connection request as fast as possible. Any data sent as part of a connect confirmation is then done in the responder. With the TLI, any data sent as part of a connect confirmation is done through the t_accept call. Hence, the way ISODE 5.2 is structured, you can't issue the t_accept until you are in the responder. This means that the connection is still pending on the listening endpoint until after the responder gets running, calls TInit to recapture state information and t_sync the endpoint (to force the provider to sync it's tables after the exec) and then call TConnResponse to finally do the t_accept and send any data. Why is this a problem? The t_accept call will fail with a T_LOOK event if during the responder process initialization a new connect request has come in on the listening endpoint. For lightly loaded hosts this is probably not a problem, for a heavily loaded host, such as a DDN gateway, it is a problem. No great solution is offered - our implementation waits to give the tsap daemon a chance to recognize the new connection (i.e., call t_listen) and then try and do the t_accept again, eventually giving up and refusing the connection because of congestion. The only other real issue was because of a problem in the WIN/3B socket select(3N) system call emulation. A select call was implemented which emulates the BSD select using the SVR3.2 poll (2) call. In addition to allowing the ISODE to select simultaneously over both TCP and TP4 streams, the new select solved an outstanding problem with FTAM file transfers hanging under SVR3.2 (over WIN TCP). Simply link in select ahead of the WIN libnet.a and everything works fine with no changes to ISODE. Bob Slaski NetWorks One uunet!netwrx1!slaski (703) 827-7767
kc@cbnewsl.ATT.COM (keith.coulson) (03/16/90)
In article <818@netwrx1.UUCP>, slaski@netwrx1.UUCP (Robert Slaski) writes: > Why is this a problem? The t_accept call will fail with a T_LOOK > event if during the responder process initialization a new connect > request has come in on the listening endpoint. For lightly loaded > hosts this is probably not a problem, for a heavily loaded host, > such as a DDN gateway, it is a problem. No great solution is offered > - our implementation waits to give the tsap daemon a chance to > recognize the new connection (i.e., call t_listen) and then try > and do the t_accept again, eventually giving up and refusing the > connection because of congestion. > Essentially the trade-off in this matter is whether you want to catch all the incoming requests or maintain the semantics of TConnResponse. Since I was doing performance tests I chose the former by doing the t_accept within my TLI version of the daemon and then forking the service. This works fine because session always accepts and does not send data with TConnResponse, at least that was the case with ISODE 5.0. So my version of TConnResponse is a dummy routine! Keith Coulson AT&T Bell Laboratories Summit NJ