TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

An abort operation will not flush pending writes and will issue a TCP ABORT command to the O/S kernel which should result in a TCP_RST packet being sent to the peer. The sender of this command and the registered handler for incoming data will both be notified once the socket is closed using a TcpAborted message.

The connection has been aborted in response to an TcpAbort command.

The Bind message is send to the TCP manager actor, which is obtained via Manager in order to bind to a listening socket. The manager replies either with a TcpCommandFailed or the actor handling the listen socket replies with a TcpBound message. If the local port is set to 0 in the Bind message, then the TcpBound message should be inspected to find the actual port which was bound to.

The sender of a TcpBind command will—in case of success—receive confirmation in this form. If the bind address indicated a 0 port number, then the contained `localAddress` can be used to find out which port was automatically assigned.

A normal close operation will first flush pending writes and then close the socket. The sender of this command and the registered handler for incoming data will both be notified once the socket is closed using a TcpClosed message.

Common interface for all commands which aim to close down an open connection.

The connection has been closed normally in response to a TcpClose command.

TBD

Whenever a command cannot be completed, the queried actor will reply with this message, wrapping the original command which failed.

A write command which aggregates two other write commands. Using this construct you can chain a number of TcpWrite and/or TcpWriteFile commands together in a way that allows them to be handled as a single write which gets written out to the network as quickly as possible. If the sub commands contain `ack` requests they will be honored as soon as the respective write has been written completely.

A confirmed close operation will flush pending writes and half-close the connection, waiting for the peer to close the other half. The sender of this command and the registered handler for incoming data will both be notified once the socket is closed using a TcpConfirmedClosed message.

The connection has been half-closed by us and then half-close by the peer in response to a TcpConfirmedClose command.

The Connect message is sent to the TCP manager actor, which is obtained via Manager. Either the manager replies with a TcpCommandFailed or the actor handling the new connection replies with a TcpConnected message.

The connection actor sends this message either to the sender of a TcpConnect command (for outbound) or to the handler for incoming connections designated in the TcpBind message. The connection is characterized by the `remoteAddress` and `localAddress` TCP endpoints.

This is the common interface for all events which indicate that a connection has been closed or half-closed.

The connection has been closed due to an IO error.

Common interface for all events generated by the TCP layer actors.

TBD

Each TcpWriteCommand can optionally request a positive acknowledgment to be sent to the commanding actor. If such notification is not desired the [!:WriteCommand#ack] must be set to an instance of this class. The token contained within can be used to recognize which write failed when receiving a TcpCommandFailed message.

The peer has closed its writing half of the connection.

Whenever data are read from a socket they will be transferred within this class to the handler actor which was designated in the TcpRegister message.

This message must be sent to a TCP connection actor after receiving the TcpConnected message. The connection will not read any data from the socket until this message is received, because this message defines the actor which will receive all inbound data.

This message enables the accepting of the next connection if read throttling is enabled for connection actors.

This command needs to be sent to the connection actor after a TcpSuspendReading command in order to resume reading from the socket.

When `useResumeWriting` is in effect as was indicated in the TcpRegister message then this command needs to be sent to the connection actor in order to re-enable writing after a TcpCommandFailed event. All TcpWriteCommand processed by the connection actor between the first TcpCommandFailed and subsequent reception of this message will also be rejected with TcpCommandFailed.

TBD

Sending this command to the connection actor will disable reading from the TCP socket. TCP flow-control will then propagate backpressure to the sender side as buffers fill up on either end. To re-enable reading send TcpResumeReading.

In order to close down a listening socket, send this message to that socket’s actor (that is the actor which previously had sent the TcpBound message). The listener socket actor will reply with a TcpUnbound message.

The sender of an TcpUnbind command will receive confirmation through this message once the listening socket has been closed.

Write data to the TCP connection. If no ack is needed use the special `NoAck` object. The connection actor will reply with a TcpCommandFailed message if the write could not be enqueued. If [!:WriteCommand#wantsAck] returns true, the connection actor will reply with the supplied [!:WriteCommand#ack] token once the write has been successfully enqueued to the O/S kernel. Note that this does not in any way guarantee that the data will be or have been sent! Unfortunately there is no way to determine whether a particular write has been sent by the O/S.

TBD

Write `count` bytes starting at `position` from file at `filePath` to the connection. The count must be > 0. The connection actor will reply with a TcpCommandFailed message if the write could not be enqueued. If WantsAck returns true, the connection actor will reply with the supplied Ack token once the write has been successfully enqueued to the O/S kernel. Note that this does not in any way guarantee that the data will be or have been sent! Unfortunately there is no way to determine whether a particular write has been sent by the O/S.

When `useResumeWriting` is in effect as indicated in the TcpRegister message, the TcpResumeWriting command will be acknowledged by this message type, upon which it is safe to send at least one write. This means that all writes preceding the first TcpCommandFailed message have been enqueued to the O/S kernel at this point.

TBD

TBD

TBD

TBD

UDP Extension for Akka’s IO layer. This extension implements the connectionless UDP protocol without calling `connect` on the underlying sockets, i.e. without restricting from whom data can be received. For "connected" UDP mode see UdpConnected. For a full description of the design and philosophy behind this IO implementation please refer to the Akka online documentation.

Send this message to the Manager in order to bind to the given local port (or an automatically assigned one if the port number is zero). The listener actor for the newly bound port will reply with a UdpBound message, or the manager will reply with a UdpCommandFailed message.

This message is sent by the listener actor in response to a UdpBind command. If the address to bind to specified a port number of zero, then this message can be inspected to find out which port was automatically assigned.

The common type of all commands supported by the UDP implementation.

When a command fails it will be replied to with this message type, wrapping the failing command object.

The common type of all events emitted by the UDP implementation.

The common interface for UdpCommand and UdpEvent.

Each UdpSend can optionally request a positive acknowledgment to be sent to the commanding actor. If such notification is not desired the Ack must be set to an instance of this class. The token contained within can be used to recognize which write failed when receiving a UdpCommandFailed message.

When a listener actor receives a datagram from its socket it will send it to the handler designated in the UdpBind message using this message type.

This message must be sent to the listener actor to re-enable reading from the socket after a `SuspendReading` command.

This message is understood by the "simple sender" which can be obtained by sending the UdpSimpleSender query to the Manager as well as by the listener actors which are created in response to UdpBind. It will send the given payload data as one UDP datagram to the given target address. The UDP actor will respond with UdpCommandFailed if the send could not be enqueued to the O/S kernel because the send buffer was full. If the given `ack` is not of type UdpNoAck the UDP actor will reply with the given object as soon as the datagram has been successfully enqueued to the O/S kernel. The sending UDP socket’s address belongs to the "simple sender" which does not handle inbound datagrams and sends from an ephemeral port; therefore sending using this mechanism is not suitable if replies are expected, use UdpBind in that case.

Retrieve a reference to a "simple sender" actor of the UDP extension. The newly created "simple sender" will reply with the UdpSimpleSenderReady notification. The "simple sender" is a convenient service for being able to send datagrams when the originating address is meaningless, i.e. when no reply is expected. The "simple sender" will not stop itself, you will have to send it a PoisonPill when you want to close the socket.

The "simple sender" sends this message type in response to a UdpSimpleSender query.

TBD

InetSocketOption to set the SO_BROADCAST option For more information see cref="System.Net.Sockets.Socket.EnableBroadcast"/>

Send this message to a listener actor (which sent a UdpBound message) to have it stop reading datagrams from the network. If the O/S kernel’s receive buffer runs full then subsequent datagrams will be silently discarded. Re-enable reading from the socket using the `ResumeReading` command.

Send this message to the listener actor that previously sent a UdpBound message in order to close the listening socket. The recipient will reply with an UdpUnbound message.

This message is sent by the listener actor in response to an `Unbind` command after the socket has been closed.

UDP Extension for Akka’s IO layer. This extension implements the connectionless UDP protocol with calling `connect` on the underlying sockets, i.e. with restricting from whom data can be received. For "unconnected" UDP mode see Udp. For a full description of the design and philosophy behind this IO implementation please refer to the Akka online documentation.

The common type of all commands supported by the UDP implementation.

When a command fails it will be replied to with this message type, wrapping the failing command object.

Send this message to the Manager in order to bind to a local port (optionally with the chosen `localAddress`) and create a UDP socket which is restricted to sending to and receiving from the given `remoteAddress`. All received datagrams will be sent to the designated `handler` actor.

This message is sent by the connection actor to the actor which sent the UdpConnectedConnect message when the UDP socket has been bound to the local and remote addresses given.

Send this message to a connection actor (which had previously sent the UdpConnectedConnected message) in order to close the socket. The connection actor will reply with a UdpConnectedDisconnected message.

This message is sent by the connection actor to the actor which sent the `Disconnect` message when the UDP socket has been closed.

The common type of all events emitted by the UDP implementation.

The common interface for UdpConnectedCommand and UdpConnectedEvent.

Each UdpConnectedSend can optionally request a positive acknowledgment to be sent to the commanding actor. If such notification is not desired the Ack must be set to an instance of this class. The token contained within can be used to recognize which write failed when receiving a UdpConnectedCommandFailed message.

When a connection actor receives a datagram from its socket it will send it to the handler designated in the UdpBind message using this message type.

This message must be sent to the listener actor to re-enable reading from the socket after a `SuspendReading` command.

This message is understood by the connection actors to send data to their designated destination. The connection actor will respond with UdpConnectedCommandFailed if the send could not be enqueued to the O/S kernel because the send buffer was full. If the given `ack` is not of type UdpConnectedNoAck the connection actor will reply with the given object as soon as the datagram has been successfully enqueued to the O/S kernel.

Send this message to a listener actor (which sent a UdpBound message) to have it stop reading datagrams from the network. If the O/S kernel’s receive buffer runs full then subsequent datagrams will be silently discarded. Re-enable reading from the socket using the `ResumeReading` command.

TBD

TBD

TBD

TBD

TBD

TBD