A-Shell Development History

908.1 - 17 Nov 04

XCALL TCPX enhanced to allow for better implementation of an AlphaBasic server that receives rapid connection requests, whether they are handed off to spawned children or by server itself. The basic problem prior to this update was that the listening socket was closed as soon as a connection was accepted. Even if the server quickly processed the request and returned to accept another connection, any connection requests arriving while the listening socket was closed would have been rejected. The new feature allows the listening socket to be kept open independently of the connection socket, and the size of the queue has been increased from 5 to 64.

To review, the syntax of TCPX.SBX is:

xcall TCPX,op,status,data,sockport{,flags{,timer{,hostname}}}

On the ACCEPT OP (1), the FLAGS argument can be a reasonable combination of following (all but the first one are new in this update):

 

Normally (when none of the last 3 flags are set), the ACCEPT operation will open a listening socket on the port specified by SOCKPORT, and then wait for a connection to be accepted. At that point, it closes the listening socket and returns the connection socket in SOCKPORT to the caller.

If the TCPXFLAG'LISTEN flag is specified, then it returns with the listening socket in SOCKPORT, without waiting for a connection. (The application should then save this returned SOCKPORT value in a separate variable, perhaps called LISTENSOCK, as it may be needed later after SOCKPORT has been again updated.)

Since opening the listening socket is fast (does not require waiting for a client to make a connection request), this eliminates the possibility of the server getting stuck for an indefinite time waiting for a client connection. It can subsequently use the CHECK OP (7) to check if a connection is ready (although it should do so frequently, since the clients do not like to wait very long.) Once a connection is ready to accept (or if it decides it doesn't mind waiting) it can use the ACCEPT OP (1) again, this time with TCPXFLG'ASYNC (and optionally, TCPXFLG'KEEPLISTEN) to accept a connection on the listening socket specified in SOCKPORT. The accepted connection socket is returned in SOCKPORT. (This would overwrite the saved listening socket number, so if you plan to accept further connections on this same listening socket, you must save the listening socket in another variable.)

If the server wants to "stay open for business" while processing the current connection, it should use the TCPXFLG'KEEPLISTEN flag so that the listening socket previously opened (and hopefully saved in a separate variable, i.e. LISTENSOCK) can be left open and reused for the next connection.

As long as the listening socket is left open, any connection requests will queue up, either until the queue fills, or the client gets tired of waiting and cancels the request. The length of the queue has been increased from 5 to 64, which should be more than adequate for most situations.

Note that if you use TCPXFLG'LISTEN, and then don't accept a connection or accept one with the TCPXFLG'KEEPLISTEN flag set, the listening socket remains open, and must be manually closed (in addition to any connection socket) when your program ends. Use the normal OP CLOSE (6) and specify the listening socket (which you hopefully saved in a variable separate from SOCKPORT.)

Opcode 6 (CLOSE), which since TCPX.SBR was introduced in 4.9 has also issued a shutdown command to the socket, now only performs the close operation. A new opcode, 5, has been added to force a shutdown. The distinction between close and shutdown is as follows:

Shutdown sends a signal to the remote end indicating the that sender is shutting down its end of the socket. Since sockets are full duplex, it is possible to shutdown just the sending side, or the receiving side or both. Two new flags, TCPXFLG'SHUTRD (32) and TCPXFLG'SHUTWR (64) have been added to allow the application to take advantage of this capability. (If both, or neither, are specified, the socket is shut down in both directions.) Shutdown does not substitute for close though, and therefore should be followed (eventually) by a normal close.

Close will generally have the same effect as a shutdown in both directions, except in the case where a socket is being shared by a parent and child process. The parent may have accepted the connection, then used XCALL SUBMIT to fork a child, which inherits the connection. Normally the parent would then close its connection socket. In the case, the close will not have any effect on the other end, since the child still has the socket open. (Shutdown, on the other hand, would cause the other end to get an error if tried to read or write to the socket.) When the child closes the socket, since it is the last one at its end to have it open, it will really be closed.

908.2 - 17 Nov 04

(Windows) New MIAMEX,138 function added to support a range of Registry operations:

xcall MIAMEX, MX'REGISTRY, opcode, <params depending on OPCODE>