Struct Connection 

pub struct Connection { /* private fields */ }

Contains the state information and implements the logic for a minimalist TCP connection.

One particular thing is that whenever the connection sends a RST segment, it will also stop working itself. This is just a design decision for our envisioned use cases; improvements/changes may happen in the future (this also goes for other aspects of the current implementation).

A Connection object can only be created via passive open, and will not recognize/use any TCP options except MSS during the handshake. The associated state machine is similar to how TCP normally functions, but there are some differences:

• Since only passive opens are supported, a Connection can only be instantiated in response to an incoming SYN segment. If the segment is valid, it will start directly in a state called SYN_RECEIVED. The valid events at this point are receiving a retransmission of the previous SYN (which does nothing), and getting the chance to write a SYNACK, which also moves the connection to the SYNACK_SENT state. Any incoming segment which is not a copy of the previous SYN will reset the connection.
• In the SYNACK_SENT state, the connection awaits an ACK for the SYNACK. A retransmission of the original SYN moves the state back to SYN_RECEIVED. A valid ACK advances the state to ESTABLISHED. Any unexpected/invalid segment resets the connection.
• While ESTABLISHED, the connection will only reset if it receives a RST or a SYN. Invalid segments are simply ignored. FIN handling is simplifed: when close is invoked the connection records the FIN sequence number, and starts setting the FIN flag (when possible) on outgoing segments. A FIN from the other endpoint is only taken into consideration if it has the next expected sequence number. When the connection has both sent and received a FIN, it marks itself as being done. There’s no equivalent for the TIME_WAIT TCP state.

The current implementation does not do any kind of congestion control, expects segments to arrive in order, triggers a retransmission after the first duplicate ACK, and relies on the user to supply an opaque u64 timestamp value when invoking send or receive functionality. The timestamps must be non-decreasing, and are mainly used for retransmission timeouts.

See mmds-design for why we are able to make these simplifications. Specifically, we want to stress that no traffic handled by dumbo ever leaves a microVM.

Implementations

impl Connection

pub fn passive_open<T: NetworkBytes + Debug>( segment: &TcpSegment<'_, T>, local_rwnd_size: u32, rto_period: NonZeroU64, rto_count_max: NonZeroU16, ) -> Result<Self, PassiveOpenError>

Attempts to create a new Connection in response to an incoming SYN segment.

Arguments

• segment - The incoming SYN.
• local_rwnd_size - Initial size of the local receive window.
• rto_period - How long the connection waits before a retransmission timeout fires for the first segment which has not been acknowledged yet. This uses an opaque time unit.
• rto_count_max - How many consecutive timeout-based retransmission may occur before the connection resets itself.

pub fn close(&mut self)

Closes this half of the connection.

Subsequent calls after the first one do not have any effect. The sequence number of the FIN is the first sequence number not yet sent at this point.

pub fn make_rst_config(&self) -> RstConfig

Returns a valid configuration for a RST segment, which can be sent to the other endpoint to signal the connection should be reset.

pub fn reset(&mut self)

Specifies that a RST segment should be sent to the other endpoint, and then the connection should be destroyed.

pub fn is_established(&self) -> bool

Returns true if the connection is past the ESTABLISHED point.

pub fn fin_received(&self) -> bool

Returns true if a FIN has been received.

pub fn is_done(&self) -> bool

Returns true if the connection is done communicating with the other endpoint.

Maybe it would be a good idea to return true only after our FIN has also been ACKed? Otherwise, when using the TCP handler there’s pretty much always going to be an ACK for the FIN that’s going to trigger a gratuitous RST (best case), or can even be considered valid if a new connection is created meanwhile using the same tuple and we get very unlucky (worst case, extremely unlikely though).

pub fn first_not_sent(&self) -> Wrapping<u32>

Returns the first sequence number which has not been sent yet for the current window.

pub fn highest_ack_received(&self) -> Wrapping<u32>

Returns the highest acknowledgement number received for the current window.

pub fn advance_local_rwnd_edge(&mut self, value: u32)

Advances the right edge of the local receive window.

This is effectively allowing the other endpoint to send more data, because no byte can be sent unless its sequence number falls into the receive window.

pub fn remote_rwnd_edge(&self) -> Wrapping<u32>

Returns the right edge of the receive window advertised by the other endpoint.

pub fn dup_ack_pending(&self) -> bool

Returns true if a retransmission caused by the reception of a duplicate ACK is pending.

pub fn control_segment_or_timeout_status(&self) -> NextSegmentStatus

Describes whether a control segment can be sent immediately, a retransmission is pending, or there’s nothing to transmit until more segments are received.

This function does not tell whether any data segments can/will be sent, because the Connection itself does not control the send buffer. Thus the information returned here only pertains to control segments and timeout expiry. Data segment related status will be reported by higher level components, which also manage the contents of the send buffer.

pub fn receive_segment<T: NetworkBytes + Debug>( &mut self, s: &TcpSegment<'_, T>, buf: &mut [u8], now: u64, ) -> Result<(Option<NonZeroUsize>, RecvStatusFlags), RecvError>

Handles an incoming segment.

When no errors occur, returns a pair consisting of how many bytes (if any) were received, and whether any unusual conditions arose while processing the segment. Since a Connection does not have its own internal buffer, buf is required to store any data carried by incoming segments.

Arguments

• s - The incoming segment.
• buf - The receive buffer where payload data (if any) from s is going to be written.
• now - An opaque timestamp representing the current moment in time.

pub fn write_next_segment<'a, R: ByteBuffer + ?Sized + Debug>( &mut self, buf: &'a mut [u8], mss_reserved: u16, payload_src: PayloadSource<'_, R>, now: u64, ) -> Result<Option<Incomplete<TcpSegment<'a, &'a mut [u8]>>>, WriteNextError>

Writes a new segment (if available) to the specified buffer.

The payload_src argument is required because the Connection does not have an internal send buffer. If the payload source is present, the data referenced therein must not amount to more than MAX_WINDOW_SIZE.

Arguments

• buf - The buffer where the segment is written.
• mss_reserved - How much (if anything) of the MSS value has been already used at the lower layers (by IP options, for example). This will be zero most of the time.
• payload_src - References a buffer which contains data to send, and also specifies the sequence number associated with the first byte from that buffer.
• now - An opaque timestamp representing the current moment in time.

Trait Implementations

impl Clone for Connection

fn clone(&self) -> Connection

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Connection

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.