Path: utzoo!attcan!uunet!husc6!rutgers!mailrus!ncar!ico!dougm
From: dougm@ico.ISC.COM (Doug McCallum)
Newsgroups: comp.unix.wizards
Subject: Re: Non blocking connect using streams/TLI?
Message-ID: <12927@ico.ISC.COM>
Date: 20 Dec 88 00:36:24 GMT
References: <488@gonzo.UUCP> <12903@ico.ISC.COM>
Reply-To: dougm@ico.isc.com (Doug McCallum)
Distribution: na
Organization: Interactive Systems Corp., Boulder CO
Lines: 27

In article <12903@ico.ISC.COM> dougm@ico.isc.com (Doug McCallum) writes:
>In article <488@gonzo.UUCP> daveb@rtech.com (Dave Brower) writes:
>...
>>streams/TLI based connection routine?  
>>
>>(This is of interest in, say a window system where select is the heart
>>of the event loop.  You'd want to make sure that other events coming in
>>won't be blocked out by a connect request to something on a slow
>>network)
>>

My response didn't indicate how to do this with connect although it
was hinted at.  If the STREAM obtained with a t_open() is put into
O_NDELAY mode, the t_connect() will not block.  When poll says there
is an event, a t_look (I think I said t_listen before) will indicate
if it is a response to the connect request and a t_rcvconnect can be
used to complete the connection.  Look at the t_rcv* functions for
more details.

Unlike BSD sockets, the TLI primitives have separate events/operations
for things like connect and connect response and receiving an incoming
connect indication and the actual acceptance of the connection.
Sockets tend to have more done in the calls.  One nice thing in TLI is
that after t_listen gives you the connection request you can decide to
accept or reject based on information provided by the t_listen.

For more casual programming, sockets tend to be a lot simpler.