From de6a8290a3bd69b6d32a1d323228d03584867d68 Mon Sep 17 00:00:00 2001 From: gdamore Date: Thu, 2 Jan 2025 17:32:19 +0000 Subject: deploy: 2e15032c278e279b67909c06c2d47c9051a493cc --- ref/tran/udp.html | 40 ++++++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 14 deletions(-) (limited to 'ref/tran/udp.html') diff --git a/ref/tran/udp.html b/ref/tran/udp.html index b74bc971..f7cb9039 100644 --- a/ref/tran/udp.html +++ b/ref/tran/udp.html @@ -236,7 +236,7 @@ that all messages sent will arrive.

This transport is experimental.

-

URI Format

+

URL Format

This transport uses URIs using the scheme udp://, followed by an IP address or hostname, followed by a colon and finally a UDP port number. @@ -278,18 +278,21 @@ and could be used to listen to port 9999 on the host:

  • udp://:9999

    • Socket Address

    -

    When using an nng_sockaddr structure, +

    When using an nng_sockaddr structure, the actual structure is either of type -nng_sockaddr_in (for IPv4) or -nng_sockaddr_in6 (for IPv6).

    +nng_sockaddr_in (for IPv4) or +nng_sockaddr_in6 (for IPv6).

    Transport Options

    The following transport options are supported by this transport, where supported by the underlying platform.

    - -

    TODO: Document other options.

    +
    + + + + + +
    OptionTypeDescription
    NNG_OPT_LOCADDRnng_sockaddrThe locally bound address, will be either nng_sockaddr_in or nng_sockaddr_in6.
    NNG_OPT_REMADDRnng_sockaddrThe remote peer address, will be either nng_sockaddr_in or nng_sockaddr_in6. Only valid for pipe and dialer objects.
    NNG_OPT_RECVMAXSZsize_tMaximum size of incoming messages, will be limited to at most 65000.
    NNG_OPT_UDP_COPY_MAXsize_tThreshold above which received messages are “loaned” up, rather than a new message being allocated and copied into.
    NNG_OPT_UDP_BOUND_PORTintThe locally bound UDP port number (1-65535), read-only for listener objects only.
    +

    Maximum Message Size

    This transport maps each SP message to a single UDP packet. In order to allow room for network headers, we thus limit the maximum @@ -298,19 +301,28 @@ message size to 65000 bytes, minus the overhead for any SP protocol headers.

    very much smaller messages, ideally those that will fit within a single network packet without requiring fragmentation and reassembly.

    For Ethernet without jumbo frames, this typically means an MTU of a little -less than 1500 bytes. (Specifically, 1452, which allows 28 bytes for IP and UDP, -and 20 bytes for the this transport). -Other link layers may have different MTUs.

    +less than 1500 bytes. (Specifically, 1452, which allows 28 bytes for IPv4 and UDP, +and 20 bytes for the this transport. Reduce by an additional 20 bytes for IPv6.)

    +

    Other link layers may have different MTUs, however IPv6 requires a minimum MTU of 1280, +which after deducting 48 bytes for IPv6 and UDP headers, and 20 bytes for our transport +header, leaves 1212 bytes for user data. If additional allowances are made for SP protocol +headers with a default TTL of 8 (resulting in 72 additional bytes for route information), +the final user accessible payload will be 1140 bytes. Thus this can be likely be viewed +as a safe maximum to employ for SP payload data across all transports.

    The maximum message size is negotiated as part of establishing a peering relationship, and oversize messages will be dropped by the sender before going to the network.

    -

    The maximum message size to receive can be configured with the -NNG_OPT_RECVMAXSZ option.

    +

    The maximum message size to receive can be configured with the NNG_OPT_RECVMAXSZ option.

    Keep Alive

    This transports maintains a logical “connection” with each peer, to provide a rough facsimile of a connection based semantic. This requires some resource on each peer. In order to ensure that resources are reclaimed when a peer vanishes unexpectedly, a keep-alive mechanism is implemented.

    TODO: Document the tunables for this.

    + + + + + -- cgit v1.2.3-70-g09d2