Connection acceptance by the server

If the server is ready to provide its special services, it assigns one of its sockets the name (address) defined for the service concerned. In order to be able to accept the connection request of a client, the server must also execute the following two steps:

1. The server uses the listen() function to mark the socket for incoming connection requests as “listening”. The server then monitors the socket, i.e. it waits passively for a connection request for this socket. It is now possible for any partner to take up contact with the server. listen() also causes SOCKETS(BS2000) to place connection requests to the socket concerned in a queue. This normally prevents any connection requests being lost while the server processes another one.

   Exception: BCAM connection timer has elapsed:
   This timer must be taken into greater consideration when using the ISO transport service since here, unlike AF_INET and AF_INET6, the connection setup acknowledgment is not generated and sent to the partner until a send action is initiated (for example with send()).

2. The server uses accept() to accept the connection for the socket marked as “listening”. You can use the function getsockopt() or recvmsg() to evaluate the connection data transferred earlier for the connection request. Unlike the Internet domain, the connection is not completely set up after cept(). The connection to the partner is not set up in its entirety until

   • user data is sent or

   • CFRM data (confirm) is sent with the sendmsg() function.

The following program extract illustrates connection acceptance by the server in the AF_ISO domain:

struct sockaddr_iso from;
... ..
listen(s, 5);
fromlen = sizeof(from);
newsock = accept(s, &from, &fromlen);
send(newsock, msg, len, flags);

The first parameter passed when listen() is called is the descriptor s of the socket on which the connection is to be set up. The second parameter defines the maximum number of connection requests which may be placed in the queue for acceptance by the server task. Note, however, that SOCKET(BS2000) does not evaluate this parameter at present and continues to accept connection requests until the maximum number of available sockets have been used.

The first parameter passed when accept() is called is the descriptor s of the socket on which the connection is to be set up. After accept() is executed, the from parameter contains the address of the partner application, and fromlen contains the length of this address. When a connection is accepted with accept(), a descriptor is created for a new socket. This descriptor returns accept() as its result. Once the execution of send() has set up the connection completely, data can be exchanged on the new socket. The server can accept additional connections on socket s.

An accept() call normally blocks because the accept() function does not return until a connection is accepted. When accept() is called, the server task also has no way of indicating that it only wants to accept connection requests from one or more specific partners. The server task must therefore note where the connection comes from and terminate it if it does not want to communicate with the client concerned. 

The following points are described in detail in the chapter "Extended SOCKETS(BS2000) functions":

• how a server task can accept connections on more than one socket

• how a server task can prevent the accept() call from blocking