🚀 go-pugleaf

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