Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!agate!ucbvax!xtel.co.uk!j.onions
From: j.onions@xtel.co.uk (Julian Onions)
Newsgroups: comp.protocols.iso.dev-environ
Subject: (none)
Message-ID: <24509.670155295@xtel.co.uk>
Date: 28 Mar 91 10:14:55 GMT
References: <9103280050.AA26872@ocfmail.ocf.llnl.gov>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 38

> 	When I use any other value in the timeout parameter, such as a 
> 60 second timeout value or the constant OK to indicate polling, I have to
> call TNetAccept twice after the connection request arrives to get the 
> argument vector filled in.
> 	Can anyone give me some information regarding why I have to call 
> TNetAccept twice?  Is it possible to only call it once and have the connectio
n
> completely established without using the NOTOK constant for a timeout?
No it is not. TNetAccept uses the timeout parameter to switch between
blocking and non-blocking mode. If the timeout is NOTOK it blocks
until a connection is accepted or a file descriptor in one of the
masks is ready for activity. If it is any other value, TNetAccept
returns as soon as anything happens. An incoming connection is
accepted in two phases normally (for TP0), firstly the system call
level does an accept(2) call to get the new conenction, then it waits
for an incoming CR-TPDU. when that is received it passes this back up
to the caller. If the timeout is anything but NOTOK it will return
after each activity (both the accept(2) and the CR-TPDU).
This is essential if you want to work asynchronously, and be able to
call yourself.

> 	This is causing problems when 2 connection requests arrive within a 
> very short time from eachother.  It seems as though the second call to
> TNetAccept is accepting the second connection request and then returning the
> file descriptor for the first connection.  
TNetAccept can return for a variety of reasons, you know if something
has been accepted because the vec.vecp stuff is filled in. I can't see
a problem with this.


> 	I am trying use ISODE over a multitasking package using 
> non-blocking i/o and I would like a different task to accept the second 
> connection request.
There is a bug in 6.0 that cause it to loose incoming conenctions
occasionally under high load with many incoming connections. This may
be related. It is fixed in isode-interim (6.8).

Julian.