Lines Matching refs:it
57 making the session part of it a Linux network protocol (AF_RXRPC).
138 initiated by the first data packet on it arriving. If security is
142 upon it use that same security. In the event that the server lets a
183 the last call currently using it has completed in case a new call is made
184 that could reuse it.
187 time [tunable] after the last connection using it discarded, in case a new
188 connection is made that could use it.
195 (*) A server-side connection is shared if the client says it is.
231 the tag is guaranteed not to be seen again, and so it can be used to pin
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
273 secret keys corresponding to the security types it permits. When a secure
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
294 (d) it fills the user buffer.
296 If recvmsg is called in blocking mode, it will keep sleeping, awaiting the
299 (2) MSG_PEEK operates similarly, but will return immediately if it has put any
300 data in the buffer rather than sleeping until it can fill the buffer.
306 (4) If there is more data to be had on a call (it hasn't copied the last byte
334 that the app specifies in the client by attaching it to the first data
335 message or in the server by passing it in association with an RXRPC_ACCEPT
336 message. recvmsg() passes it in conjunction with all messages except
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
370 encountered and that a call has been aborted because of it. An
384 assign it a user ID. It should be associated with an RXRPC_USER_CALL_ID
386 accepted (it may have timed out, been aborted, etc.), then sendmsg will
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
493 socket used - usually IPv4 but it can also be IPv6 [TODO].
577 secret keys in it:
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.
608 it a message for each. This is received with recvmsg() on the server
616 the time it is accepted - in which case the first call still on the queue
630 to collect as it arrives. All but the last piece of the request data will
646 when it is received. It will take the form of a dataless message with two
678 rather than having to open a whole slew of sockets, one for each key it
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.
723 returned. The caller now holds a reference on this and it must be
752 This is used to abort a call if it's still in an abortable state. The
794 called on it..
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
824 (*) Record the delivery of a data message and free it.
843 to be received for a call (true will be returned if it does, false
891 generate a soft-ACK to tell the sender that it doesn't need to resend.
897 the sender it can free its buffers, assuming no other reason occurs that
903 transmit it again, assuming no ACK is received from the receiver telling
904 us they got it.
909 before we preemptively kill it.
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,
927 remove it from the transport list. Whilst a transport is in existence, it