Lines Matching refs:a
5 The RxRPC protocol driver provides a reliable two-phase transport on top of UDP
37 RxRPC is a two-layer protocol. There is a session layer which provides
39 layer, but implements a real network protocol; and there's the presentation
57 making the session part of it a Linux network protocol (AF_RXRPC).
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
80 (2) provided with a protocol of the type of underlying transport they're going
102 (*) Each connection goes to a particular "service". A connection may not go
104 a port number. AF_RXRPC permits multiple services to share an endpoint.
106 (*) Client-originating packets are marked, thus a transport endpoint can be
107 shared between client and server connections (connections have a
110 (*) Up to a billion connections may be supported concurrently between one
122 (*) Each RxRPC operation is a "call". A connection may make up to four
123 billion calls, but only up to four calls may be in progress on a
130 (*) The data blobs are of indefinite size, the end of a phase is marked with a
137 (*) Security is negotiated on a per-connection basis. The connection is
139 requested, the server then issues a "challenge" and then the client
140 replies with a "response". If the response is successful, the security is
142 upon it use that same security. In the event that the server lets a
150 A hard-ACK indicates to the far side that all the data received to a point
151 has been received and processed; a soft-ACK indicates that the data has
155 (*) Reception of a reply data packet implicitly hard-ACK's all the data
180 concurrent calls, up to a tunable limit.
182 (*) Each connection is retained for a certain amount of time [tunable] after
183 the last call currently using it has completed in case a new call is made
186 (*) Each internal UDP socket is retained [tunable] for a certain amount of
187 time [tunable] after the last connection using it discarded, in case a new
209 (*) A socket is made into a server socket by binding an address with a
212 (*) In the client, sending a request is achieved with one or more sendmsgs,
215 (*) The first sendmsg for a request to be sent from a client contains a tag to
219 (*) connect() is used to supply a default destination address for a client
221 first sendmsg() of a call (struct msghdr::msg_name).
223 (*) If connect() is called on an unbound client, a random local port will
230 (*) Once the application has received the last message associated with a call,
235 (*) In the server, a request is received with one or more recvmsgs, then the
237 is received with a last recvmsg.
239 (*) When sending data for a call, sendmsg is given MSG_MORE if there's more
242 (*) When receiving data for a call, recvmsg flags MSG_MORE if there's more
245 (*) When receiving data or messages for a call, MSG_EOR is flagged by recvmsg
254 an abort or a busy message terminates the kernel's use of that call's tag.
256 (*) The control data part of the msghdr struct is used for a number of things:
266 (*) When the kernel has received and set up an incoming call, it sends a
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
269 application then uses sendmsg to assign a tag to the new call. Once that
272 (*) The server application has to provide the server socket with a keyring of
273 secret keys corresponding to the security types it permits. When a secure
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
279 (*) The name of the key a client will use to secure its communications is
280 nominated by a socket option.
285 (*) If there's a sequence of data messages belonging to a particular call on
288 (a) it meets the end of that call's received data,
290 (b) it meets a non-data message,
292 (c) it meets a message belonging to a different call, or
302 (3) If a data message is only partially consumed in filling a user buffer,
306 (4) If there is more data to be had on a call (it hasn't copied the last byte
322 RXRPC_ACK -rt n/a Final ACK received
324 RXRPC_BUSY -rt n/a Call rejected (server busy)
326 RXRPC_NEW_CALL -r- n/a New call received
327 RXRPC_ACCEPT s-- n/a Accept new call
341 This is can be used by an application to abort a call by passing it to
342 sendmsg, or it can be delivered by recvmsg to indicate a remote abort was
349 This is delivered to a server application to indicate that the final ACK
350 of a call was received from the client. It will be associated with an
363 This is delivered to a client application to indicate that a call was
369 This is delivered to an application to indicate that a local error was
370 encountered and that a call has been aborted because of it. An
377 This is delivered to indicate to a server application that a new call has
379 as a user ID must subsequently be assigned by doing an RXRPC_ACCEPT.
383 This is used by a server application to attempt to accept a call and
384 assign it a user ID. It should be associated with an RXRPC_USER_CALL_ID
395 AF_RXRPC sockets support a few socket options at the SOL_RXRPC level:
408 Similar to above but specifies a keyring of server secret keys to use (key
422 (a) RXRPC_SECURITY_PLAIN
467 They have a description of "<serviceID>:<securityIndex>" (eg: "52:2" for an
468 rxkad key for the AFS VL service). When such a key is created, it should be
474 A keyring is passed to the server socket by naming it in a sockopt. The server
499 .srx_service = 0, /* we're a client */
507 This specifies the local UDP port to be used. If not given, a random
509 several unrelated RxRPC sockets. Security is handled on a basis of
517 This issues a request_key() to get the key representing the security
537 (5) The request data should then be posted to the server socket using a series
545 If a call is intended to go to a destination other than the default
551 for a particular call to be read. MSG_EOR will be set on the terminal
552 read for a call.
576 (2) Security is set up if desired by giving the socket a keyring with server
608 it a message for each. This is received with recvmsg() on the server
609 socket. It has no data, and has a single dataless control message
619 (5) The server then accepts the new call by issuing a sendmsg() with two
637 (8) The reply data should then be posted to the server socket using a series
643 for a particular call.
646 when it is received. It will take the form of a dataless message with two
656 aborted by calling sendmsg() with a dataless message with the following
665 Note that all the communications for a particular service take place through
675 such as the AFS filesystem. This permits such a utility to:
678 rather than having to open a whole slew of sockets, one for each key it
681 (2) Avoid having RxRPC call request_key() at the point of issue of a call or
682 opening of a socket. Instead the utility is responsible for requesting a
693 To use the RxRPC facility, a kernel utility must still open an AF_RXRPC socket,
694 bind an address as appropriate and listen if it's to be a server socket, but
699 (*) Begin a new client call.
708 This allocates the infrastructure to make a new RxRPC call and assigns
710 the socket is bound to. The call will go to the destination address of a
714 If a key is supplied then this will be used to secure the call instead of
719 control data buffer. It is entirely feasible to use this to point to a
723 returned. The caller now holds a reference on this and it must be
726 (*) End a client call.
730 This is used to end a previously begun call. The user_call_ID is expunged
734 (*) Send data through a call.
739 This is used to supply either the request part of a client call or the
740 reply part of a server call. msg.msg_iovlen and msg.msg_iov specify the
745 The msg must not specify a destination address, control data or any flags
748 (*) Abort a call.
752 This is used to abort a call if it's still in an abortable state. The
792 be the last one in a sequence with rxrpc_kernel_is_data_last(). When a
798 freeing, but this may pin the state of a call until the message is finally
807 This is used to accept an incoming call and to assign it a call ID. This
812 returned. The caller now holds a reference on this and it must be
820 a BUSY message. -ENODATA is returned if there were no incoming calls.
824 (*) Record the delivery of a data message and free it.
828 This is used to record a data message as having been delivered and to
831 (*) Free a message.
835 This is used to free a non-DATA socket buffer intercepted from an AF_RXRPC
838 (*) Determine if a data message is the last one on a call.
842 This is used to determine if a socket buffer holds the last data message
843 to be received for a call (true will be returned if it does, false
846 The data message will be part of the reply on a client call and the
854 This is used to extract the abort code from a remote abort message.
856 (*) Get the error number from a local or network error message.
860 This is used to extract the error number from a message indicating either
861 a local error occurred or a network error occurred.
863 (*) Allocate a null key for doing anonymous security.
867 This is used to allocate a null RxRPC key that can be used to indicate
868 anonymous security for a particular domain.
875 The RxRPC protocol driver has a number of configurable parameters that can be
880 The amount of time in milliseconds after receiving a packet with the
885 reception window is full (to a maximum of 255 packets), so delaying the
890 The amount of time in milliseconds after receiving a new packet before we
891 generate a soft-ACK to tell the sender that it doesn't need to resend.
896 received queue have been consumed before we generate a hard-ACK to tell
902 The amount of time in milliseconds after transmitting a packet before we
908 The maximum amount of time in seconds that a call may be in progress
913 The amount of time in seconds before we remove a dead call from the call
914 list. Dead calls are kept around for a little while for the purpose of
919 The amount of time in seconds after a connection was last used before we
920 remove it from the connection list. Whilst a connection is in existence,
921 it serves as a placeholder for negotiated security; when it is deleted,
926 The amount of time in seconds after a transport was last used before we
927 remove it from the transport list. Whilst a transport is in existence, it
943 The maximum number of packets that we're willing to accept in a jumbo
944 packet. Non-terminal packets in a jumbo packet must contain a four byte
946 a four byte header plus any amount of data. In any event, a jumbo packet