Chuck Shotton on Listeners

Here's an excerpt from an email from Chuck on the theory of listeners.

Here is a generic, language independent description of how listens should work.

1. A thread is spawned to handle queuing up a listen (and ultimately handling the connection when established).

2. The thread creates a record, table, variable, or some other "thing" that contains stuff like the port, the stream, and a completion flag. The latter is important.

3. The thread sends the LIST event with the address (or some other reference) to this "thing" passed as the refcon.

4. NetEvents creates a stream, starts the listen, and returns the stream in the direct parameter of the reply to the LIST event.

5. The thread sits in an idle loop doing 2 things. First, it looks to see if the completion flag is set. If so, it knows the connection is complete and there is a client standing by for servicing. If not, it checks to see if a sufficient amount of time has passed (say 45 seconds). If so, then it sends a STAT event to see if the stream is still valid and to reset NetEvents' timer for that listening stream to prevent it from timing out after 60 seconds. (Note that this timeout is the timeout used by the idle stream killer inside NetEvents and is unrelated to the timeout value specified in the LIST event.) If nothing is going on, it yields to other threads.

6. A connection arrives for the listening stream inside NetEvents. NetEvents determines the remote client's address and packages that info up with the refcon and stream and sends a LISC event to your application (NOT your thread necessarily).

7. Your application's handler for the LISC event pulls out all the parameters, looks at the data pointed to by the refcon parameter, and sets the completion flag indicating that the listen is now complete.

8. Your thread (as in step 5) now sees the completion flag get set and goes about its business talking to the client with reads, writes, etc.

What this means for Frontier is that some convention for completion flags needs to be established. Perhaps just passing the address of an integer in the refcon that can be twiddled by the LISC trap would be sufficient?

---

© Copyright 1996-97 UserLand Software. This page was last built on 5/7/97; 1:20:55 PM. It was originally posted on 2/13/97; 1:08:32 PM. Internet service provided by Conxion.