Lines Matching refs:then

59  (2) A two-phase protocol.  The client transmits a blob (the request) and then
60      receives a blob (the reply), and the server receives the request and then
127      which the service receives; then the service transmits the reply data
139      requested, the server then issues a "challenge" and then the client
232      client resources.  A new call can then be initiated with the same tag
235  (*) In the server, a request is received with one or more recvmsgs, then the
236      the reply is transmitted with one or more sendmsgs, and then the final ACK
269      application then uses sendmsg to assign a tag to the new call.  Once that
275      in the keyring and then sends a challenge packet to the client and
276      receives a response packet.  The kernel then checks the authorisation of
286      the receive queue, then recvmsg will keep working through them until:
303      then the remainder of that message will be left on the front of the queue
307      of the last data message in that phase yet), then MSG_MORE will be
344      specify the call affected.  If an abort is being sent, then error EBADSLT
386      accepted (it may have timed out, been aborted, etc.), then sendmsg will
388      then error EBADSLT will be returned.
475 socket then looks the server secret keys up in this keyring when secure
524  (4) The server to be contacted can then be specified (alternatively this can
537  (5) The request data should then be posted to the server socket using a series
546      specified through connect(), then msghdr::msg_name should be set on the
549  (6) The reply data will then be posted to the server socket for recvmsg() to
591  (2) A local address must then be bound:
603  (3) The server is then set to listen out for incoming calls:
619  (5) The server then accepts the new call by issuing a sendmsg() with two
625  (6) The first request data packet will then be posted to the server socket for
637  (8) The reply data should then be posted to the server socket using a series
684      operations such as open() or unlink().  The key is then handed through
695 then it passes this to the kernel interface functions.
714      If a key is supplied then this will be used to secure the call instead of
767      then diverted to this function.  Note that care must be taken to process