Lines Matching refs:to
6 that can be used to perform RxRPC remote operations. This is done over sockets
7 of AF_RXRPC family, using sendmsg() and recvmsg() with control data to send and
40 layer which renders structured data to binary blobs and back again using XDR
64 to speed up subsequent calls.
66 (4) A secure protocol, using the Linux kernel's key retention facility to
71 left to the application. AF_RXRPC only deals in blobs. Even the operation ID
81 to use - currently only PF_INET is supported.
95 currently), and uses this to provide network transport. UDP ports, for
99 endpoint, thus allowing the endpoints to be shared, even to the same
102 (*) Each connection goes to a particular "service". A connection may not go
103 to multiple services. A service may be considered the RxRPC equivalent of
104 a port number. AF_RXRPC permits multiple services to share an endpoint.
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
132 not exceed 4 billion, however, as this would cause the sequence number to
146 (*) Calls use ACK packets to handle reliability. Data packets are also
150 A hard-ACK indicates to the far side that all the data received to a point
162 (*) An call may be aborted by either end at any time up to its completion.
172 protocol to represent transport endpoints.
175 connections are handled transparently. One client socket may be used to
176 make multiple simultaneous calls to the same service. One server socket
179 (*) Additional parallel client connections will be initiated to support extra
180 concurrent calls, up to a tunable limit.
193 able to share connections with each other.
200 (*) SO_KEEPALIVE automatically pings the other side to keep the connection
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
220 socket. This may be overridden by supplying an alternate address to the
226 (*) A server socket may also be used to make client calls. To do this, the
228 transport endpoint is used to send the packets.
231 the tag is guaranteed not to be seen again, and so it can be used to pin
240 data to come on that call.
243 data to come for that call.
246 to indicate the terminal message for that call.
248 (*) A call may be aborted by adding an abort control message to the control
253 and control data messages will be set to indicate the context. Receiving
267 message to server application to let it know there's a new call awaiting
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
279 (*) The name of the key a client will use to secure its communications is
285 (*) If there's a sequence of data messages belonging to a particular call on
292 (c) it meets a message belonging to a different call, or
306 (4) If there is more data to be had on a call (it hasn't copied the last byte
315 AF_RXRPC makes use of control messages in sendmsg() and recvmsg() to multiplex
316 calls, to invoke certain actions and to report certain conditions. These are:
321 RXRPC_ABORT srt Abort code Abort code to issue/received
333 This is used to indicate the application's call ID. It's an unsigned long
334 that the app specifies in the client by attaching it to the first data
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
343 received. Either way, it must be associated with an RXRPC_USER_CALL_ID to
349 This is delivered to a server application to indicate that the final ACK
351 RXRPC_USER_CALL_ID to indicate the call that's now complete.
355 This is delivered to an application to indicate that an ICMP error message
356 was encountered in the process of trying to talk to the peer. An
363 This is delivered to a client application to indicate that a call was
364 rejected by the server due to the server being busy. It will be
365 associated with an RXRPC_USER_CALL_ID to indicate the rejected call.
369 This is delivered to an application to indicate that a local error was
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
385 to indicate the user ID to be assigned. If there is no call to be
399 This is used to specify the description of the key to be used. The key is
403 The optval pointer points to the description string, and optlen indicates
408 Similar to above but specifies a keyring of server secret keys to use (key
413 This is used to request that new connections should be used for each call
418 This is used to specify the minimum security level required for calls on
419 this socket. optval must point to an int containing one of the following
442 (security index 2 - rxkad). This requires the rxkad module to be loaded and,
443 on the client, tickets of the appropriate type to be obtained from the AFS
450 The payload provided to add_key() on the client should be of the following
463 Where the ticket blob is just appended to the above structure.
466 For the server, keys of type "rxrpc_s" must be made available to the server.
474 A keyring is passed to the server socket by naming it in a sockopt. The server
507 This specifies the local UDP port to be used. If not given, a random
517 This issues a request_key() to get the key representing the security
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
545 If a call is intended to go to a destination other than the default
549 (6) The reply data will then be posted to the server socket for recvmsg() to
551 for a particular call to be read. MSG_EOR will be set on the terminal
559 buffer instead, and MSG_EOR will be flagged to indicate the end of that
567 A server would be set up to accept operations in the following manner:
588 The keyring can be manipulated after it has been given to the socket. This
589 permits the server to add more keys, replace keys, etc. whilst it is live.
603 (3) The server is then set to listen out for incoming calls:
625 (6) The first request data packet will then be posted to the server socket for
626 recvmsg() to pick up. At that point, the RxRPC address for the call can
629 Subsequent request data will be posted to the server socket for recvmsg()
630 to collect as it arrives. All but the last piece of the request data will
637 (8) The reply data should then be posted to the server socket using a series
652 MSG_EOR will be flagged to indicate that this is the final message for
655 (10) Up to the point the final packet of reply data is sent, the call can be
666 the one server socket, using control messages on sendmsg() and recvmsg() to
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
679 might want to use.
687 (3) Request the use of something other than GFP_KERNEL to allocate memory.
694 bind an address as appropriate and listen if it's to be a server socket, but
695 then it passes this to the kernel interface functions.
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
715 the key bound to the socket with the RXRPC_SECURITY_KEY sockopt. Calls
718 The user_call_ID is equivalent to that supplied to sendmsg() in the
719 control data buffer. It is entirely feasible to use this to point to a
722 If this function is successful, an opaque reference to the RxRPC call is
730 This is used to end a previously begun call. The user_call_ID is expunged
739 This is used to supply either the request part of a client call or the
741 data buffers to be used. msg_iov may not be NULL and must point
742 exclusively to in-kernel virtual addresses. msg.msg_flags may be given
746 other than MSG_MORE. len is the total amount of data to transmit.
752 This is used to abort a call if it's still in an abortable state. The
767 then diverted to this function. Note that care must be taken to process
768 the messages in the right order to maintain DATA message sequentiality.
772 to the call and the socket buffer containing the message.
791 socket buffer manipulation functions. A data message can be determined to
796 Non-data messages should be handled to rxrpc_kernel_free_skb() to dispose
797 of. It is possible to get extra refs on all types of message for later
807 This is used to accept an incoming call and to assign it a call ID. This
808 function is similar to rxrpc_kernel_begin_call() and calls accepted must
811 If this function is successful, an opaque reference to the RxRPC call is
819 This is used to reject the first incoming call on the socket's queue with
828 This is used to record a data message as having been delivered and to
835 This is used to free a non-DATA socket buffer intercepted from an AF_RXRPC
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
854 This is used to extract the abort code from a remote abort message.
860 This is used to extract the error number from a message indicating either
867 This is used to allocate a null RxRPC key that can be used to indicate
885 reception window is full (to a maximum of 255 packets), so delaying the
886 ACK permits several packets to be ACK'd in one go.
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
928 serves to anchor the peer data and keeps the connection ID counter.
933 unconsumed received packets we're willing to hold in memory for any
938 The maximum packet MTU size that we're willing to receive in bytes. This
939 indicates to the peer whether we're willing to accept jumbo packets.
943 The maximum number of packets that we're willing to accept in a jumbo