Lines Matching refs:server

26  (*) Example server usage.
60      receives a blob (the reply), and the server receives the request and then
67      manage security on the client end.  The server end must of necessity be
107      shared between client and server connections (connections have a
139      requested, the server then issues a "challenge" and then the client
142      upon it use that same security.  In the event that the server lets a
160      reached the server.
176      make multiple simultaneous calls to the same service.  One server socket
195  (*) A server-side connection is shared if the client says it is.
209  (*) A socket is made into a server socket by binding an address with a
226  (*) A server socket may also be used to make client calls.  To do this, the
227      first sendmsg() of the call must specify the target address.  The server's
235  (*) In the server, a request is received with one or more recvmsgs, then the
267      message to server application to let it know there's a new call awaiting
268      its acceptance [recvmsg reports a special control message].  The server
272  (*) The server application has to provide the server socket with a keyring of
324 	RXRPC_BUSY		-rt n/a		Call rejected (server busy)
335      message or in the server by passing it in association with an RXRPC_ACCEPT
349      This is delivered to a server application to indicate that the final ACK
364      rejected by the server due to the server being busy.  It will be
377      This is delivered to indicate to a server application that a new call has
383      This is used by a server application to attempt to accept a call and
408      Similar to above but specifies a keyring of server secret keys to use (key
444 kaserver or the kerberos server and installed as "rxrpc" type keys.  This is
466 For the server, keys of type "rxrpc_s" must be made available to the server.
469 given the server's secret key as the instantiation data (see the example
474 A keyring is passed to the server socket by naming it in a sockopt.  The server
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
549  (6) The reply data will then be posted to the server socket for recvmsg() to
567 A server would be set up to accept operations in the following manner:
571 	server = socket(AF_RXRPC, SOCK_DGRAM, PF_INET);
576  (2) Security is set up if desired by giving the socket a keyring with server
586 	setsockopt(server, SOL_RXRPC, RXRPC_SECURITY_KEYRING, "AFSkeys", 7);
589      permits the server to add more keys, replace keys, etc. whilst it is live.
601 	bind(server, &srx, sizeof(srx));
603  (3) The server is then set to listen out for incoming calls:
605 	listen(server, 100);
607  (4) The kernel notifies the server of pending incoming connections by sending
608      it a message for each.  This is received with recvmsg() on the server
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
629      Subsequent request data will be posted to the server socket for recvmsg()
637  (8) The reply data should then be posted to the server socket using a series
666 the one server socket, using control messages on sendmsg() and recvmsg() to
694 bind an address as appropriate and listen if it's to be a server socket, but
740      reply part of a server call.  msg.msg_iovlen and msg.msg_iov specify the
780 	RXRPC_SKB_MARK_BUSY		Client call rejected as server busy