Enhanced maximum transmission unit (MTU) discovery

Abstract

Embodiments of the application relate to enhanced maximum transmission unit (MTU) discovery. In response to receiving a first runtime identifier from a server device, a client device can transmit a probe packet to the server device via a socket. The probe packet can have a size and can include a request for a runtime identifier. The client device can receive a response to the probe packet from the server device via the socket. The response can indicate that the probe packet was successfully received at the server device and can include a second runtime identifier. In response to determining that the first runtime identifier and the second runtime identifier identify an uninterrupted runtime of the server device, the client device can store the size as a maximum transmission unit (MTU) setting for the socket. The client device can transmit a data packet to the server device via the socket using the MTU setting.

Description

Background Technology

[0001] Modern network environments include diverse and complex network topologies. Therefore, data transmitted from a source node to different destination nodes can traverse network paths with different properties. For example, network paths can include varying numbers and combinations of components, such as intermediate devices (e.g., network switches, routers, gateways, etc.), Virtual Private Networks (VPNs), etc. Attached Figure Description

[0002] Some implementations of this disclosure are described with reference to the following figures.

[0003] Figure 1 This is a flowchart of an enhanced discovery process for MTU settings, based on some examples;

[0004] Figure 2 It is a flowchart based on some examples of the process for performing an MTU test and determining whether the MTU test is successful;

[0005] Figure 3 This is a flowchart based on some examples of the process used to test the default MTU settings;

[0006] Figure 4A It is a block diagram illustrating an MTU test along a network path connecting a client device to various server devices with default MTU settings, based on some examples.

[0007] Figure 4B It is a block diagram illustrating MTU testing along the network path connecting client devices to various server devices under known MTU settings, based on some examples.

[0008] Figure 5 It is a flowchart based on some examples of the process for discovering the MTU settings for a socket;

[0009] Figure 6 It is a block diagram of a computing device that can discover the MTU settings for a socket, based on some examples; and

[0010] Figure 7 This is a block diagram of a machine-readable storage medium 700 with instructions for discovering the MTU settings for a socket, based on some examples.

[0011] In all the accompanying drawings, the same reference numerals indicate similar but not necessarily identical elements. The drawings are not necessarily drawn to scale, and the dimensions of some parts may be exaggerated to illustrate the examples shown more clearly. Furthermore, the drawings provide examples and / or implementations consistent with the specification; however, this specification is not limited to the examples and / or implementations provided in the drawings. Detailed Implementation

[0012] Devices in a network path can be configured with different Maximum Transmission Unit (MTU) settings, thus limiting the maximum data packet size allowed to be transmitted by each device. Differences in MTU settings between devices in a network path (e.g., MTU mismatch) can lead to packet loss or fragmentation. For example, a data packet transmitted by the source node using a first MTU setting might be discarded by an intermediate device with a second, smaller MTU setting.

[0013] Maximizing the MTU setting used to transmit packets between a source node and a destination node can increase the efficiency of communication between these nodes because a higher MTU setting size can support the transmission of information using packets with larger sizes. However, discovering the maximized (e.g., optimal) MTU setting can be complicated by problems in the network and / or at the destination node. For example, to discover an MTU setting suitable for communicating with the destination node, the source node can test the MTU setting, which may involve attempting to transmit packets to the destination node using that MTU setting (e.g., probing packets). In some cases, if the packet is dropped, the tested MTU setting can be considered unsuitable for communicating with the destination node, and the source node can continue searching for a suitable MTU setting by reducing or otherwise changing the MTU setting being tested.

[0014] However, packets can be dropped due to various issues, such as MTU mismatch, target node downtime, or network failures connecting the source and target nodes. In this regard, if packets are dropped due to issues unrelated to the MTU setting (e.g., problems with the network and / or the target node), the tested MTU setting is considered inappropriate, and continuing the search can lead to an MTU setting below the size supported by the network path. As a result, the source node can use a suboptimal MTU setting, which can reduce its communication efficiency with the target node.

[0015] In some cases, Path MTU Discovery (PMTUD) can be used to determine the MTU setting for a source node. Using PMTUD, when a source node can attempt to transmit a packet of a given size, multiple intermediate devices forwarding that packet and having an MTU setting smaller than the given size may drop the packet and transmit an Internet Control Message Protocol (ICMP) error message to the source node. This can signal that the MTU setting for the source node should be reduced. However, the usability of PMTUD is limited for several reasons. First, PMTUD relies on ICMP messages that are allowed by all devices in the network path, and ICMP messages are typically blocked by network devices for security purposes. Second, PMTUD may fail on network paths involving dynamic Network Address Translation (NAT) devices, such as routers employing dynamic NAT. For example, because PMTUD operates at the Internet layer (e.g., using ICMP), it can identify an MTU setting that is only suitable for transmission to dynamic NAT devices. However, besides dynamic NAT devices, data packets can traverse paths specific to their destination ports, and these paths may include multiple other network devices with different MTU settings. Third, PMTUD fails to account for Virtual Private Network (VPN) practices with additional Internet Protocol (IP) headers. For example, adding an IP header to data packets for transmission over a VPN can cause data packets to exceed the MTU settings of another device in the network path. Finally, PMTUD does not allow packet fragmentation (e.g., PMTUD sets a "Do Not Fragment (DF)" flag), which can lead to inefficient MTU settings and reduce network flexibility.

[0016] To address these issues, the examples described herein relate to enhanced discovery of MTU settings for connections between client devices (e.g., source nodes) and server devices (e.g., target nodes). Enhanced discovery may involve a client device testing the MTU setting by transmitting a probe packet to the server device in response to receiving a first runtime identifier from the server device. The probe packet may have a size and may include a request for the runtime identifier. Enhanced discovery may also involve the client device receiving a response from the server device to the probe packet. This response may indicate that the probe packet has been successfully received at the server device and may include a second runtime identifier, which may be provided by the server device in response to a request for the runtime identifier. In response to determining that the first and second runtime identifiers identify the uninterrupted runtime of the server device, the client device may store the size of the probe packet as the MTU setting of the socket. The client device may also use this MTU setting to transmit data packets to the server device via the socket.

[0017] By using runtime identifiers during enhanced discovery, client devices can verify whether a server device is undergoing runtime (e.g., powered on, operational, etc.) at one or more points. Runtime identifiers (e.g., tokens) can be numbers, strings, etc., that identify the runtime period of the server device and can be generated by the server device. Runtime identifiers can remain static during the server device's runtime and can be changed (e.g., refreshed) when the server device experiences downtime (e.g., shutdown, restart, inoperability, etc.). Therefore, client devices can use runtime identifiers to verify whether the server device can be contacted via the network, indicating that the server device is undergoing runtime and the network is operational. Client devices can also use (e.g., compare) a set of runtime identifiers to verify whether the server device has undergone uninterrupted runtime between transmissions within that set.

[0018] In some examples, if the server device is unreachable, the client device can wait for the server device to become reachable. In this regard, the client device can wait for the server device to become reachable (which can be indicated by receiving a first runtime identifier) ​​to transmit probe packets. The client device can also use (e.g., compare) the first runtime identifier and the second runtime identifier received from the server device to determine whether the server device experienced uninterrupted runtime or downtime while the client device was testing the MTU setting associated with the probe packets. For example, a match between the first runtime identifier and the second runtime identifier can indicate that the server device experienced uninterrupted runtime, while a mismatch can indicate that the server device experienced interrupted runtime (e.g., downtime).

[0019] Based on the determination that the server device has experienced an interruption in uptime, the client device can determine that failed or interrupted communication with the server device was caused by a problem unrelated to the MTU setting (e.g., a problem at the server device). In the event of an interruption in uptime on the server device, the client device can re-verify the server device's availability and can restart and / or repeat parts of the process to discover the MTU setting. By verifying whether the server device is experiencing uptime at various points, the client device can therefore prevent the MTU setting size discovered for the connection from falling below the size supported by the network path. Therefore, the enhanced discovery described herein can provide an MTU setting superior to that provided by alternative MTU discovery techniques (e.g., a larger MTU setting).

[0020] The enhanced discovery described herein can also involve connection-based discovery. As described herein, a connection can be a channel (e.g., a link) that enables inter-process communication from a source to a destination address and port over a network (e.g., via a network path). A socket can be an endpoint for this connection and can therefore include a socket address, which is a combination of a network destination address and a port number. Communication via a socket or a socket-like interface (which has a network destination address and a port number and can be interchangeably referred to as a socket) can involve the use of the transport layer, either directly (e.g., using transport layer protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc.) or indirectly (e.g., using higher-level layers, such as the application layer that uses the transport layer for communication).

[0021] Therefore, transmitting probe packets via sockets can involve using the transport layer. In some examples, the client device may also transmit probe packets to another socket at the server device, so that the probe packets are transmitted to the network destination address and port number at the server device. In response to receiving the probe packets, the server device can transmit a response to the client device. The client device can receive the response via sockets, which again involves using the transport layer. The client device can use the response to determine whether the probe packets have been successfully received at the server device, and successful reception of the probe packets can indicate that the connection between the client device and the server device supports an MTU setting corresponding to a given size.

[0022] By using the transport layer (e.g., using sockets), the MTU setting can be discovered without using ICMP messages, thereby reducing the risk of information related to MTU setting discovery being blocked by network devices for security purposes. Furthermore, by using the transport layer in the manner described herein, client devices can discover the MTU setting applicable to end-to-end connections between client and server devices, unaffected by packet fragmentation and / or components included in the network path (such as dynamic NAT devices, VPNs, etc.). In this respect, client devices can determine the MTU setting based on successfully transmitting probe packets and receiving corresponding responses, while remaining unaware of packet fragmentation and / or components in the network path used to perform this action.

[0023] Figure 1 This is a flowchart of an enhanced discovery process 100 for setting the MTU of a socket associated with a connection between a client device and a server device, based on some examples. Process 100 may be performed according to a method stored on a machine-readable storage medium (e.g., Figure 6 Machine-readable storage medium 620 Figure 7The process 100 is implemented in the form of executable instructions and / or electronic circuit devices on a machine-readable storage medium 700, etc. In some examples, the operation of process 100 can be performed by a client device (e.g., Figure 2 Client device 205, client device 405 in Figure 4, Figure 6 The computing device 600 (which may be a computing device) executes by executing instructions. Although Figure 1 The diagram shows the tasks to be executed in a given order, but these tasks can also be executed in a different order, some tasks can be omitted, and other tasks can be added.

[0024] As described herein, a client device can use process 100 to discover the MTU setting for connecting to a server device, an MTU setting suitable for communication with the server device (e.g., supported by the connection). Specifically, the client device can discover the MTU setting of the socket associated with the connection. The client device can also use process 100 to maximize the value of the discovered MTU setting. For example, process 100 may involve verifying whether the server device is experiencing runtime issues to avoid reducing the MTU setting size below what the connection supports.

[0025] In some examples, the client device can (at 105) perform an MTU test with the minimum MTU setting and can (at 110) determine whether the MTU test with the minimum MTU setting was successful. The minimum MTU setting can be the smallest size of the MTU setting, which can be defined by the network protocol used for the connection between the client device and the server device, such as Internet Protocol version 4 (IPv4), Internet Protocol version 6 (IPv6), etc. As an illustrative example, the minimum MTU setting under IPv4 can be 576 bytes (e.g., octets), while the minimum MTU setting under IPv6 can be 1280 bytes.

[0026] To perform an MTU test with the minimum MTU setting, the client device can attempt to communicate with the server device via a connection using the minimum MTU setting, as per [reference needed]. Figure 2 As described in more detail. For example, a client device can use a socket to transmit probe packets that have a size matching the minimum size and include a request for a runtime identifier. To determine whether the MTU test (at 110) was successful with the minimum MTU setting, the client device can determine whether the communication attempt with the server device was successful. (See also: ...) Figure 2 As described, a client device can determine whether communication is successful based on one or more handshakes, messages (e.g., packets and / or responses) exchanged between the client device and the server device.

[0027] A successful MTU test with the minimum MTU setting indicates that the server device is reachable over the network, as successful communication with the client device indicates that the server device is experiencing runtime (e.g., powered on, operational, etc.) and is reachable over the network. Therefore, in some examples, the client device can perform an MTU test with the minimum MTU setting to verify that the server device is reachable. In response to determining that the server device is reachable (e.g., in response to a successful MTU test with the minimum MTU setting), the client device can (at 120) store a runtime identifier received from the server, and as described in more detail herein, the client device can use this runtime identifier to verify that the server device has maintained continuous runtime without being interrupted by downtime.

[0028] A successful MTU test with the minimum MTU setting also indicates that the connection supports the minimum MTU setting (e.g., the minimum MTU setting is suitable for communication between the client device and the server device). Since the minimum MTU setting can be defined by the network protocol used to facilitate communication between the client device and the server device, the connection between the client device and the server device (according to the protocol) should at least support the minimum MTU setting. In this respect, an unsuccessful (e.g., failed) MTU test with the minimum MTU setting does not indicate that the connection does not support the minimum MTU setting, but rather may indicate that a problem unrelated to the MTU setting (such as network and / or server device issues) has interrupted communication between the client device and the server device.

[0029] For example, an unsuccessful MTU test with the minimum MTU setting can indicate that the server device is unreachable. The server device may be unreachable due to problems at the server device itself, problems with the network connecting the client device and the server device, etc. For example, the server device may be unreachable during periods of server downtime (e.g., during times when the server device is not running); the server device may also be unreachable if a problem prevents the network from connecting the client device to the server device.

[0030] In response to determining that the MTU test has failed, the client device can (at 115) wait for a predetermined (e.g., pre-configured) delay period. As an illustrative example, the delay period could be 1 millisecond (ms), 10 ms, 100 ms, 1 second (s), 10 s, 100 s, etc. In some examples, while waiting (at 115), the client device can sleep, enter a low-power mode, perform operations unrelated to process 100, perform operations related to other connections (e.g., associated with a different server device), etc. As described above, the MTU test may fail due to problems with the server device and / or the network used to transmit probe packets. Therefore, by waiting for the predetermined delay period to elapse, the client device can (at 105) repeat the MTU test with the minimum MTU setting after the problems with the server device and / or the network have been resolved. In this respect, since the MTU test may fail with any MTU setting when the server is unreachable, the client device can confirm whether the server device is reachable and can wait until the server device is reachable before testing (e.g., discovering the MTU setting) other MTU settings.

[0031] In response to a successful MTU test (at 110) with the minimum MTU setting, the client device may (at 120) store the runtime identifier received from the server. In some examples, when performing an MTU test with the minimum MTU setting, the client device may receive the runtime identifier from the server device. For example, as described in more detail herein, the server device may transmit a runtime identifier to the client device in response to a request for the runtime identifier, which may be included in a probe packet transmitted by the client device. The client device may store the runtime identifier in a cache, memory, storage device, etc., associated with the socket and / or the connection to the server device.

[0032] Runtime identifiers can be numbers, strings, etc., that identify a period of time during which a server device is running. They remain static during the runtime and are changed based on interruptions to that runtime (e.g., due to server shutdown, restart, inoperability, etc.). For example, a runtime identifier can be a random number (e.g., a token) generated by the server to identify a specific runtime. Additionally or alternatively, a runtime identifier can be a timestamp. For example, a timestamp can identify the start time of a runtime (e.g., the time the server powers on, restarts, etc.).

[0033] In response to the determination (at 110) that the MTU test was successful with the minimum MTU setting, the client device can also discover the MTU setting of the socket associated with the connection between the client device and the server device by testing one or more different MTU settings. In this regard, in response to receiving a runtime identifier (e.g., a first runtime identifier), the client device can transmit a probe packet via the socket, the probe packet having a size and including a request for the runtime identifier. Specifically, the client device can (at 125) perform an MTU test with an MTU setting of N, where N represents a specific size. The client device can (at 130) determine whether the MTU test with the MTU set to N was successful; and if unsuccessful, the client device 130 can (at 135) change the value of N and (at 125) perform an MTU test with the updated value of N.

[0034] Task 125 can be similar to Task 105 and can be performed as described regarding Task 105. In this regard, to perform an MTU test with an MTU setting of N, the client device can attempt to communicate with the server device via a connection using an MTU set to N. Specifically, the client device can transmit probe packets via a socket, the probe packets being of size N, and including a request for a runtime identifier from the server device. In some examples, the client device can (at 125) perform an MTU test with the MTU set to an initial value of N. The initial value of N can be the maximum size used for the MTU setting. The maximum size used for the MTU setting can be the size configured at the client device, such as the system-configured MTU setting. In some examples, the maximum size used for the MTU setting can be determined by the capabilities of the client device, and devices with different capabilities can be configured with different maximum sizes for the MTU setting.

[0035] The client device can (at 130) determine whether the MTU test was successful with the MTU set to N. In some examples, task 130 can be similar to task 110 and executed as described regarding task 110. In this regard, the client device can determine whether the MTU test was successful with the MTU set to N based on one or more handshakes, messages (e.g., packets and / or responses) exchanged between the client device and the server device.

[0036] A successful MTU test with the MTU set to N indicates (from an end-to-end perspective) that the connection between the client device and the server device supports an MTU setting of N. In this respect, with the MTU set to N, the client device can successfully transmit packets to the server device via a socket (using the transport layer), and the client device can also successfully receive packets (such as responses) from the server device at the socket (using the transport layer). Therefore, in the event of a successful MTU test, the client device can receive a response to the probe packet from the server device via the socket (transmitted in relation to the MTU test at 125). This response indicates that the probe packet has been successfully received at the server device, as per the information regarding... Figure 2 As illustrated and described in more detail, the response may also include a runtime identifier from the server device (e.g., a second runtime identifier).

[0037] For N values ​​greater than the minimum MTU setting, a failed MTU test may indicate that the connection does not support an MTU setting of N and / or that the server device is unreachable. For N values ​​not greater than the minimum MTU setting, a failed MTU test may indicate that an MTU setting of N is unreachable, as described in more detail herein.

[0038] In response to the determination (at 130) that the MTU test failed with the MTU set to N, the client device can (at 135) change the MTU setting to be tested by changing the value of N. In some examples, the client device can change the value of N by decrementing it by a certain amount. For example, in response to the determination that the MTU test failed with the largest MTU setting, the client device can decrement the value of N to perform an MTU test with a smaller MTU setting.

[0039] In some examples, the client device can (at 135) change the value of N by incrementing it by a certain amount. For example, the initial value of N could be the minimum size for the MTU setting, and in response to determining that an MTU test is successful with the minimum MTU setting, the client device can increment the value of N by a certain amount and perform an MTU test with the MTU setting set to the updated value of N to discover the MTU setting used for the connection. Furthermore, in some examples, the initial value of N can be between the maximum and minimum size of the MTU setting. Therefore, the client device can change its value by incrementing or decrementing the value of N. For example, in some examples, the client device can first test the MTU setting with the initial value and values ​​greater than the initial value (by incrementing the value of N (at 135)), and then test the MTU setting with values ​​less than the initial value (by decrementing the value of N (at 135)). Alternatively, the client device can first test the MTU settings with an initial value and values ​​less than the initial value (by decrementing the value of N (at 135)), and then test the MTU settings greater than the initial value (by incrementing the value of N (at 135)).

[0040] In some examples, the maximum size used for the MTU setting is used as the initial value of N, and the value of N is decremented to discover that the MTU setting can be more efficient than the alternative methods. In this respect, the client device can test fewer MTU settings than in examples using the alternative methods (e.g., by performing (multiple) MTU tests (at 125)). For example, in the method where the MTU setting size increases as they are tested, locating the highest value of the MTU setting that will cause the MTU test to succeed can involve testing up to the point of failure, which can involve multiple successful MTU tests and then backtracking to the previous MTU setting size. In contrast, by decrementing from the maximum MTU setting, the highest MTU setting size can be identified when the MTU test succeeds.

[0041] In some examples, each time the client device executes task 135 of process 100, it can (at 135) change the value of N by a fixed size. As an illustrative example, the client device can (at 125) test a first value of N, and can change the value of N by a fixed size in response to determining that the MTU test failed (at 130), thereby changing it to a different second value of N. The client device can (at 125) test that second value of N, and can again change the value of N by a fixed size in response to determining that the MTU test failed (at 130), thereby changing it to a third value of N. This fixed size can be an integer value. Examples of fixed sizes can include 1 byte, 5 bytes, 10 bytes, 50 bytes, 100 bytes, etc. In some examples, the client device can change the value of N by a variable amount. For example, the client device can reduce the first value of N by a first size to produce a second value of N; and in response to determining that the MTU test succeeded with that MTU setting, the client device can increase the second value of N by a different second size to produce a third value of N. Furthermore, in some examples, the client device can change the value of N based on the response received from the server device. For instance, in response to determining that the length of the response is shorter than expected by a certain number of bytes, the client device can reduce the value of N by that number of bytes.

[0042] As shown in the figure, in some examples, the client device can (at 140) verify that the updated value of N is not less than the minimum MTU setting size by, for example, comparing the value of N with the minimum MTU setting size. While using an MTU setting size smaller than the minimum MTU setting size can facilitate communication between the client device and the server device, communication using such an MTU setting size can be inefficient, especially compared to communication using a larger MTU setting size (e.g., involving larger packet sizes). In this regard, since the minimum MTU setting can be defined by the network protocol used to facilitate communication between the client device and the server device, the connection between the client device and the server device (according to the protocol) should at least support the minimum MTU setting. Therefore, by verifying that the updated N value is not less than the minimum MTU setting size, the client device can ensure that the packet size used to communicate with the server device does not exceed the size set by the minimum MTU setting supported by the connection.

[0043] Furthermore, in some examples, a value of N below the minimum MTU setting can indicate that the server device cannot be contacted while the client device is performing tasks 125-140(multiple) of the operation. In this regard, one or more MTU tests may fail (at 130) not because the MTU setting is unsupported, but because communication between the client device and the server device is interrupted due to problems with the server device (such as server device experiencing downtime) and / or network issues. Therefore, the verification (at 140) can be further used as a verification of whether the server device is contactable.

[0044] In response to determining that the value of N is less than the minimum MTU setting size, the client device can restart process 100 by performing an MTU test (at 105) with the minimum MTU setting. As described herein, by performing an MTU test with the minimum MTU setting, the client device can verify whether the server device is contactable. In some cases, the client device can alternatively repeat task 135 by changing the value of N to an alternative value. For example, in response to decrementing the value of N by a step size (which results in N being less than the minimum MTU setting size), the client device can increment the value of N, or it can revert to a previous value of N and decrement that value by a smaller step size. On the other hand, in response to determining that the value of N is not less than the minimum MTU setting size, the client device can perform an MTU test (at 125) with the updated value of N as the MTU setting.

[0045] In response to the determination (at 130) that the MTU test was successful with the MTU set to N, the client device can (at 145) determine whether the runtime identifiers received from the server device match. As described above, the runtime identifier can be a token (e.g., a random number), a timestamp, etc. Therefore, comparing the first runtime identifier and the second runtime identifier can involve comparing tokens, comparing timestamps, etc. In determining whether the runtime identifiers match, the client device can verify that the final size of the size N and the MTU setting has not been changed (e.g., reduced) due to downtime of the server device (at 135). In this regard, when the client device tests various MTU settings(e.g., performs and / or repeats tasks 125-140), the client device can verify that the server device has experienced uninterrupted runtime to ensure that any failed MTU test (identified at 130) is not due to downtime of the server device (a problem unrelated to the MTU setting).

[0046] In some examples, a client device can compare a first runtime identifier received in association with an MTU test with a minimum MTU setting (e.g., received at 105) with a second runtime identifier received in association with an MTU test with an MTU setting size of N (e.g., received at 125). For example, the runtime identifier stored at 120 could be the first runtime identifier, while the second runtime identifier could be the runtime identifier received at 125. The difference between the first and second runtime identifiers can indicate that the server experienced downtime at some point after the server transmitted the first runtime identifier, because the server device can maintain a static runtime identifier during the server device's runtime and can change (e.g., refresh) the runtime identifier during downtime. On the other hand, a match between the first and second runtime identifiers can indicate that the server experienced uninterrupted runtime between the transmissions of the first and second runtime identifiers (e.g., between an MTU test with a minimum MTU setting and an MTU test with an MTU setting size of N).

[0047] The client device may (at 145) additionally or alternatively compare a runtime identifier received in response to a probe packet having a first MTU setting size of N with a runtime identifier received in response to a probe packet having a second MTU setting size of N. For example, in some examples, the client device may (at 125) perform an MTU test with an MTU setting of N having a first value of N, receive a first runtime identifier from the server device, change the value of N to a second value of N (at 135), perform an MTU test with an MTU setting of N having a second value of N (at 125), receive a second runtime identifier from the server device, and (at 145) compare the first runtime identifier and the second runtime identifier.

[0048] In response to the determination (at 145) of a runtime identifier mismatch, the client device can restart process 100 by performing an MTU test (at 105) with the minimum MTU setting. In this regard, the client device can verify the server device's contactability and can continue to discover the MTU setting.

[0049] In response to determining (at 145) a runtime identifier match, the client device can (at 150) store size N as the MTU setting for the socket associated with the connection. In this regard, in response to determining that the first runtime identifier and the second runtime identifier identify the uninterrupted runtime of the server device, the client device can store size N (e.g., the size of probe packets transmitted in relation to MTU testing at 125) as the MTU setting for the socket. The client device can store the runtime identifier in a cache, memory, storage device, etc., associated with the socket. In some examples, the client device can use the stored MTU setting for the socket to communicate between the client device and the server device without repeating process 100.

[0050] In some examples, stored MTU settings can be reset (e.g., reset to default values, such as the client device's pre-configured value, null, etc.). For instance, if a client device stores size N as its MTU setting in a cache memory, the cache memory (including the MTU settings stored therein) can be reset when the client device is powered off or restarted. Furthermore, stored MTU settings can be reset if the connection between the client device and the server device abruptly or unexpectedly terminates, because the MTU settings supported by the connection between the client device and the server device may have changed. As an illustrative example, in some cases where an intermediate device in the network path between the client device and the server device fails, an alternative path can be used to transmit packets between the client device and the server device, and the MTU settings supported by the alternative path may differ from the previously stored MTU settings.

[0051] A client device can (at 155) use a stored MTU setting (e.g., the socket's MTU setting) to transmit data via the socket. For example, a client device can use the socket's MTU setting to transmit data packets to a server device via the socket; this could involve transmitting data packets with a size set based on the socket's MTU setting. In some examples, the data packets may include data to be delivered to the server device, rather than a pattern used for MTU testing purposes. Although data packets and probe packets are described separately, in some examples, data packets can be used as probe packets.

[0052] As described herein, a client device can be a computing device (e.g., a compute node) that runs an application and communicates with a server device, while the server device can be another computing device. For example, while running an application, a client device can request information and / or services from a server device, and the server device can respond to the request by transmitting the requested information and / or performing the requested service. In some examples, the client device may establish a connection with the server device via a network to facilitate this communication. Although the examples are described with reference to client and server devices, it is understood that the operations described herein can be performed by any suitable computing device (e.g., a compute node).

[0053] As further described herein, the network connecting client devices and server devices (e.g., via a network path) can use wired communication, wireless communication, or a combination thereof. Furthermore, the network can include multiple sub-networks, such as data networks, wireless networks, telephone networks, etc. Such networks can include, for example, public data networks such as the Internet, Local Area Networks (LANs), Wide Area Networks (WANs), Metropolitan Area Networks (MANs), wired networks, fiber optic networks, combinations thereof, etc. In some examples, wireless networks can include cellular networks, satellite communications, wireless LANs, etc. Additionally, the network can take the form of direct network links between devices. Various communication structures and infrastructures can be used to implement (multiple) networks.

[0054] Figure 2 This is a flowchart of process 200, based on some examples, for performing an MTU test for a given MTU setting of a connection and determining whether the MTU test is successful under the given MTU setting. Process 200 may be tasks 105-110 ( Figure 1 Tasks 125-130 Figure 1 ), and / or tasks 305-310 ( Figure 3 Example of process 200. Process 200 can be performed according to the method of storage on a machine-readable storage medium (e.g., Figure 6 Machine-readable storage medium 620 Figure 7 The process 200 is implemented in the form of executable instructions and / or electronic circuit devices on a machine-readable storage medium 700, etc. As shown, process 200 can be executed by a client device 205 and a server device 210 (each of which can be a computing device) by executing instructions stored in the machine-readable medium. Examples of client devices may include client device 405 of FIG4. Figure 6 The computing device 600, etc., and examples of server devices may include server device 410 of Figure 4. Figure 6 Computing device 600, etc. Additionally, in some examples, the components used to execute process 200 may be distributed across multiple devices. Although Figure 2 The diagram shows the tasks to be executed in a given order, but these tasks can be executed in a different order, some tasks can be omitted, and other tasks can be added.

[0055] To perform an MTU test under a given MTU setting (with a given MTU size), client device 205 may attempt to communicate with server device 210 via a connection and using the transport layer. In some examples, client device 205 may use the transport layer by using sockets (e.g., TCP sockets, UDP sockets, etc.) to pass a target network address and port number, which may involve using a transport layer protocol (e.g., TCP, UDP, etc.). For example, when communicating via a TCP socket, the client device may use TCP; and when communicating via a UDP socket, the client device may use UDP. In some examples, the client device may indirectly use the transport layer to communicate with the server device, for example by using a protocol layer (such as the application layer) that utilizes the transport layer. In this respect, the client device may use an application layer protocol (such as HTTP) to attempt to communicate with the server device. Furthermore, in some examples, when communicating with the server device using a higher layer (e.g., the application layer), the client device may use sockets or socket-like interfaces (with a target network address and port number), which may also be referred to as sockets. Therefore, the techniques described herein are applicable to techniques involving the transport layer and / or higher layers (e.g., the application layer).

[0056] To communicate with the server device, client device 205 can (at 212) set the MTU setting for the socket to a given size. Setting the MTU setting for the socket can involve setting the maximum segment size (MSS) for the socket. In this respect, the MTU setting can be associated with the MSS so that client device 205 can also set the MTU setting by setting the MSS. For example, the MTU setting size can include the number of bytes to accommodate the MSS and the number of bytes used for header information (such as IP headers and / or TCP headers). For example, if the IP header and TCP header together are 40 bytes, client device 205 can determine the MSS by subtracting 40 bytes from the MTU setting size. The client device can set the MTU setting by setting the MSS to a value determined based on the expected MTU setting size (e.g., by subtracting an amount from the expected MTU setting size). In some examples, client device 205 can use an application programming interface (API) (such as a socket API) to set the MSS at the socket.

[0057] To perform MTU testing with the minimum MTU settings (e.g., in...) Figure 1At point 105, the client device 205 can set the MTU setting to the minimum MTU setting size (e.g., by setting the MSS accordingly). (See also: Regarding...) Figure 1 As described, in some examples, client device 205 can use a minimum MTU setting to verify whether server device 210 is contactable. This is in contrast to situations where the MTU is set to N (e.g., in...). Figure 1 The client device 205 can perform an MTU test at point 125 (where N represents a specific size), and can set the MTU setting to the size of N (e.g., by setting the MSS accordingly). As further described, the client device 205 can perform an MTU test (multiple times) for various values ​​of N to discover the MTU setting.

[0058] In some examples, to communicate with the server device, client device 205 can establish a protocol connection with server device 210. To establish this connection, client device 205 and server device 210 can (at 215) perform a (multiple) handshake using a given MTU setting (set at 212). In some examples, client device 205 and server device 210 can perform a (multiple) handshake to establish a socket and / or other protocol connection over the network. For example, to form a TCP connection (for a TCP socket), client device 205 and server device 210 can perform a TCP handshake (e.g., a three-way TCP handshake). Specifically, client device 205 can transmit a synchronization request (SYN) to server device 210, server device 210 can respond with a synchronization acknowledgment (SYN-ACK), and in response, client device 205 can transmit an acknowledgment (ACK) to server device 210. In other examples, client device 205 can establish a socket without performing a (multiple) handshake. For example, a UDP socket can be a UDP-dependent socket, where UDP is a connectionless protocol that can operate without establishing a protocol (e.g., UDP) connection.

[0059] In some examples, client device 205 and server device 210 may perform an additional handshake to establish a Transport Layer Security (TLS) connection (e.g., a TLS session), which can provide security and reliability for the connection. For example, TCP-based TLS can provide encryption and authentication of the data exchanged between client device 205 and server device 210. Client device 205 and server device 210 may perform an additional handshake to negotiate the encryption algorithm to be used in the TLS session and the keys used for encryption and authentication. Client device 205 may also perform an additional handshake to verify that it is interacting with a valid server. Similar to the TCP handshake, client device 205 and server device 210 may exchange multiple messages during the additional handshake. In some cases, the messages exchanged in the additional handshake may exceed the size of the messages exchanged in the TCP handshake, because the additional handshake may involve the transfer of one or more certificates for the aforementioned tasks.

[0060] Client device 205 can determine (at 220) whether the (multiple) handshake was successful. Client device 205 can determine the success of the (multiple) handshake based on messages received or not received from server device 210. In this respect, the (multiple) handshake can specify the sequence of messages to be exchanged between client device 205 and server device 210. Based on the successful receipt of messages specified by the (multiple) handshake, client device 205 can determine that the (multiple) handshake has been successfully performed. Based on the failure to receive messages specified by the (multiple) handshake (e.g., failure to receive messages within a timeout period), client device 205 can determine that the (multiple) handshake was not successfully performed.

[0061] In determining whether the (multiple) handshake was successful, the client device 205 can determine whether the MTU test failed given the MTU settings (set at 212). In this regard, the MTU test may fail at any stage, including during the (multiple) handshake (e.g., at 215), during the transmission of probe packets, etc.

[0062] In some examples, the messages transmitted in the TCP handshake may be relatively small. In this respect, because the size of the messages used for the TCP handshake may be smaller than the MTU setting (even the minimum MTU setting), the TCP handshake is unlikely to fail based on an unsupported MTU setting size (e.g., based on an MTU mismatch). In some cases, the messages exchanged in the additional handshake used to establish TLS may exceed the size of the messages exchanged in the TCP handshake, as the additional handshake may involve transmitting one or more certificates for the aforementioned tasks. In some cases, the size of the message including the certificate, or any other message transmitted in this additional handshake, may satisfy the given MTU setting (set at 245), and an MTU mismatch can cause the additional handshake to fail because the message may be discarded (e.g., discarded by a device that does not support the MTU setting). In this respect, the failure of (multiple) handshakes can cause the MTU test for a given MTU setting to fail, which can indicate that the connection does not support that MTU setting and / or that server device 210 cannot be contacted.

[0063] In the case of an MTU test with a minimum MTU setting, since the minimum MTU setting can be defined by the network protocol used to facilitate communication between client device 205 and server device 210, the connection between client device 205 and server device 210 (according to the protocol) should at least support the minimum MTU setting. Therefore, failure of (multiple) handshakes can cause the MTU test with the minimum MTU setting to fail, which can indicate that problems unrelated to the MTU setting (such as network and / or server device 210 problems) have interrupted communication between the client device and the server device. For example, server device 210 may be unable to contact due to downtime, network problems, problems with intermediate devices in the network path, etc.

[0064] In the case of an MTU test with an MTU set to N, where N exceeds the minimum MTU setting, the failure of (multiple) handshakes can cause the MTU test to fail for a given MTU setting, which can indicate that the connection does not support that MTU setting and / or that server device 210 cannot be contacted.

[0065] In response to the determination (at 220) that the handshake failed (which could correspond to the determination that the MTU test failed with a given MTU setting), the client device can (at 240) perform one or more failed MTU test operations, as described in more detail below. In response to the determination (at 220) that the handshake successfully completed, the client device 205 can (at 225) attempt to communicate with the server device 210 by transmitting probe packets to the server device 210 with the given MTU setting. For testing the given MTU setting, the probe packet size can be matched to the given MTU setting size. Furthermore, as shown, the probe packet can include a pattern that signals a request for a response (REQ) from the server, and a request for a runtime identifier. Although the pattern and runtime identifier request are described separately, in some examples, the pattern may include a runtime identifier request. Furthermore, although the probe packet is described and depicted as having a specific pattern, in some examples, the probe packet may be a data packet with information to be transmitted to the server device 210.

[0066] As described herein, client device 205 can transmit probe packets via the transport layer. For example, client device 205 can transmit probe packets via a socket (e.g., a TCP socket, UDP socket, etc.) associated with (e.g., related to) server device 210. Client device 205 can transmit probe packets to the corresponding socket at server device 210. In some examples, such as by using a protocol layer (e.g., the application layer) that utilizes the transport layer, the client device can indirectly use the transport layer to communicate with the server device. By transmitting probe packets via the transport layer (directly or indirectly), client device 205 can test (at the protocol layer used by the application running on client device 205, rather than a lower protocol layer (e.g., the Internet layer)) whether client device 205 can communicate with server device 210 over a connection using a given MTU setting.

[0067] In some examples, client device 205 may permit packet fragmentation during probe packet transmission (e.g., by client device 205 and / or intermediate devices); while in other examples, client device 205 may prohibit packet fragmentation during probe packet transmission. For example, client device 205 may use the "Do Not Fragment" (DF) flag in the IP header of the probe packet to indicate whether packet fragmentation is permitted. To permit packet fragmentation, client device 205 may transmit probe packets with the DF flag set to a first value (e.g., the DF flag is set to 0); and to prohibit packet fragmentation, client device 205 may transmit probe packets with the DF flag set to a second value (e.g., the DF flag is set to 1). In some examples, the first value may be the default value of the DF flag. Therefore, client device 205 may maintain the default value of the DF flag to transmit probe packets with packet fragmentation, and client device 205 may change the value of the DF flag by setting it to the second value to transmit probe packets without packet fragmentation.

[0068] In response to receiving a probe packet, server device 210 may (at 230) transmit a response to client device 205. Server device 210 may transmit this response via a transport layer (such as via a socket). As shown, the response may include a mode that signals an acknowledgment (ACK) to client device 205, and a first runtime identifier. The first runtime identifier may identify the runtime of the server device, remain static during this runtime, and be changed when server device 210 experiences downtime (e.g., shutdown, restart, etc.). Although the mode and runtime identifier are described separately in the response, in some examples, the response may incorporate the runtime identifier request into the mode. Furthermore, in some examples, client device 205 may receive the response via a transport layer (such as via a socket at client device 205).

[0069] As described above, in some examples, client device 205 may permit packet fragmentation in the transmission of probe packets. In the case of fragmented probe packets, receiving probe packets at server device 210 may involve receiving the fragmented probe packets and reassembling those fragments into probe packets. In some examples, server device 210 may permit packet fragmentation in the transmission of responses (e.g., by server device 210 and / or intermediate devices). For example, in response to client device 205 permitting packet fragmentation (such as in response to receiving a probe packet indicating that packet fragmentation is permitted), server device 210 may permit packet fragmentation. As described with respect to client device 205, for example, server device 210 may use the "Do Not Fragment" (DF) flag in the IP header of the response to indicate whether packet fragmentation is permitted. In other examples, server device 210 may disable packet fragmentation in the transmission of responses. For example, in response to client device 205 prohibiting packet fragmentation (such as in response to receiving a probe packet indicating prohibition of packet fragmentation (e.g., having a DF flag set to a second value), server device 210 may prohibit packet fragmentation.

[0070] Although server device 210 is illustrated as transmitting a response to client device (at 230), in some examples, server device 210 may fail to receive probe packets. For example, if server device 210 becomes unreachable, it may fail to receive probe packets. In the event that server device 210 fails to receive probe packets, it may also fail to transmit a response. Furthermore, in some cases, server device 210 may receive probe packets but may fail to transmit a response to client device 205. For example, if server device 210 experiences downtime before transmitting a response, it may fail to transmit a response. In some cases, server device 210 may transmit a response to client device 205, but client device 205 may fail to receive the response. For example, the response may be dropped by an intermediate device, or the network may experience problems with interrupted response transmission.

[0071] Therefore, client device 205 can (at 235) use the response (or lack thereof) to determine whether the probe packet has been successfully received at server device 210. In some examples, client device 205 can determine that the probe packet has been successfully received based on receiving a response at client device 205. Additionally or alternatively, the client device can examine the size and / or content of the response to determine whether the probe packet has been successfully received. For example, a match between the size of the probe packet and the size of the response can indicate that the probe packet has been successfully received. In some cases, a match between the content of the probe packet (e.g., the pattern included in the probe packet) and the content of the response (e.g., the pattern included in the response) can indicate that the probe packet has been successfully received. In other examples, server device 210 can generate a response by overriding the pattern received in the probe packet (e.g., changing its value). In this case, client device 205 can determine whether the probe packet has been successfully received at server device 210 based on the entire pattern included in the probe packet being overridden in the response.

[0072] Furthermore, as described above, in some examples, server device 210 may permit packet segmentation during response transmission. In the case of a segmented response, receiving the response at client device 205 may involve receiving the segments of the response and reassembling them into a new response. In this case, client device 205 may also determine that the probe packet has been successfully received based on receiving the entire response (e.g., each segment of the response) at client device 205.

[0073] On the other hand, to determine that the probe packet was not successfully received, client device 205 can determine that it failed to receive a response within the timeout period. If client device 205 receives a response (e.g., within the timeout period), it can determine that the probe packet was not successfully received based on the response not having the expected size and / or not including the expected content. For example, client device 205 can determine that the probe packet was not successfully received based on a mismatch between the size of the probe packet and the size of the response and / or a mismatch between the content of the probe packet and the content of the response. In some examples, it is determined that the probe packet was not successfully received at server device 210 based on the fact that less than the entire pattern included in the probe packet was covered in the response.

[0074] When determining whether a probe packet has been successfully received, the client device 205 can also determine whether an MTU test has been successfully performed under a given MTU setting. If the client device 205 determines (at 235) that a probe packet has been successfully received, the client device 205 can determine that an MTU test has been successfully performed under a given MTU setting. Conversely, if the client device 205 determines (at 235) that a probe packet has not been successfully received, the client device 205 can determine that an MTU test has not been successfully performed under a given MTU setting.

[0075] In some cases, the network path used to transmit probe packets from client device 205 to server device 210 may be different from the network path used to transmit the second response from server device 210 to client device 205. Specifically, the network path may support a different MTU setting for packets sent in the first direction (from client device 205 to server device 210) than for packets sent in the second direction (from server device 210 to client device 205). Therefore, by determining whether the probe packet was successfully received at server device 210 based on the response, client device 205 can determine that the network path supports the tested MTU setting regardless of the direction of packet propagation.

[0076] By determining whether a probe packet has been successfully received at server device 210 based on the response, client device 205 can also identify an MTU setting suitable for (e.g., supported by) the end-to-end connection between client device 205 and server device 210, unaffected by packet fragmentation and / or components included in the network path (such as dynamic NAT devices, VPNs, etc.). In this respect, the client device can determine the MTU setting based on the successful transmission of a probe packet and the receipt of a corresponding response, while remaining unaware of packet fragmentation and / or components in the network path used to perform this operation. For example, given the MTU setting, client device 205 can successfully transmit packets to server device 210 via a socket, and client device 205 can successfully receive packets (such as responses) from server device 210 at the socket, thereby confirming at the protocol layer (e.g., at the transport layer) used by the application running on client device 205 that client device 205 can communicate with server device 210 through the connection. Packets whose size is determined based on the MTU setting and transmitted between client device 205 and server device 210 can also be successfully forwarded (with or without packet fragmentation) via (multiple) intermediate devices and / or via (multiple) components included in the network path between client device and server device.

[0077] A failure to receive probe packets can cause an MTU test for a given MTU setting to fail, indicating that the connection does not support that MTU setting and / or that server device 210 is unable to contact. In the case of an MTU test with a minimum MTU setting, since the minimum MTU setting can be defined by the network protocol used to facilitate communication between client device 205 and server device 210, the connection between client device 205 and server device 210 (according to the protocol) should at least support the minimum MTU setting. Therefore, determining that a probe packet is not successfully received can cause an MTU test for a minimum MTU setting to fail, indicating that a problem unrelated to the MTU setting (such as a network and / or server device 210 problem) has interrupted communication between the client device and server device. For example, server device 210 may be unable to contact due to downtime, network problems, problems with intermediate devices in the network path, etc.

[0078] In response to determining (at 235) that the probe packet was not successfully received (which could correspond to determining that the MTU test failed for a given MTU setting), client device 205 may (at 240) perform one or more failed MTU test operations. In some examples, performing one or more failed MTU test operations (at 240) may involve retrying the MTU setting (e.g., repeating the MTU test for that MTU setting). For example, in the case of a minimum MTU setting, as with regard to task 115 ( Figure 1 As described, client device 205 can wait for a predetermined (e.g., pre-configured) delay period before retrying the MTU test with the minimum MTU setting, in order to provide time to resolve problems at server device 210 and / or in the network. In this regard, client device 205 can wait for a predetermined delay before retrying the (multiple) handshake (at 215) and / or retrying the transmission of probe packets (at 225) with the minimum MTU setting.

[0079] In some examples, performing one or more failed MTU test operations (at 240) can involve testing different MTU settings, as in task 135. Figure 1 ) and / or Task 325 ( Figure 3As described herein. For example, in some cases, client device 205 may change the size of the MTU setting to be tested. Client device 205 can then test the size of the changed MTU setting by, for example, restarting process 200 at the changed size. In some examples, to change the MTU setting, client device 205 may disconnect (e.g., terminate) the protocol connection, change the MTU setting, and re-establish the protocol connection (or establish a new connection) at the changed MTU setting. For example, client device 205 may disconnect a socket to change the MTU setting at that socket. Re-establishing the protocol connection and / or setting the MTU setting for the connection may involve the operations described herein with respect to tasks 212 and / or 215. While changing the MTU setting may involve disconnecting the protocol connection and re-establishing the protocol connection (or establishing a new protocol connection), as described herein, a series of protocol connections used to connect client device 205 to server device 210 using the techniques described herein can be collectively referred to as the common "protocol connection". For example, a socket with a first MTU setting that connects client device 205 to a specific target address and port, and a socket with a second MTU setting that connects client device 205 to a specific target address and port, can each be referred to as a common socket for client device 205.

[0080] In response to determining (at 235) that the first probe packet has been successfully received (which could correspond to determining that an MTU test was successful for a given MTU setting), client device 205 can (at 245) perform one or more successful MTU test operations. In some examples, performing one or more successful MTU test operations may involve storing the runtime identifier received from server device 210 and testing (multiple) other MTU settings, as per tasks 120-125. Figure 1 As described in the description. In some examples, performing one or more successful MTU test operations may involve comparing runtime identifiers received from the server device, as in the case of task 145 ( Figure 1 As described in the text. In some examples, performing one or more successful MTU test operations may involve storing a given MTU setting and using the stored MTU setting to transfer data, as described in tasks 315-320. Figure 3 As described.

[0081] In some examples, the client device can discover the MTU setting used for the connection when the connection is initialized. For example, the client device can execute procedure 100 before sending data packets to the server device. Figure 1 ) and / or process 200 ( Figure 2The client device discovers the MTU setting through the operation of [process 100]. Under this MTU setting, the client device can transmit data packets. In other examples, the client device can selectively discover the MTU setting. For example, the client device can periodically, according to a schedule, etc., perform process 100 ([process 100]). Figure 1 ) and / or process 200 ( Figure 2 The operation of ) . For example, regarding Figure 3 As described, the client device can additionally or alternatively perform such operations in response to events such as an MTU test failure in response to the default MTU setting.

[0082] Figure 3 This is a flowchart of process 300, based on some examples, for testing the default MTU settings of sockets associated with connections between client and server devices. Process 300 may be stored on a machine-readable storage medium (e.g., Figure 6 Machine-readable storage medium 620 Figure 7 The operation is implemented in the form of executable instructions and / or electronic circuit devices on a machine-readable storage medium (e.g., 700). In some examples, the operation at each of the method blocks 305-320 can be performed by a client device (e.g., Figure 2 Client device 205, client device 405 in Figure 4, Figure 6 The computing device 600 (which may be a computing device) executes by executing instructions stored in a machine-readable medium. Although Figure 3 The diagram shows the tasks to be executed in a given order, but these tasks can also be executed in a different order, some tasks can be omitted, and other tasks can be added.

[0083] The client device can (at 305) perform an MTU test with the default MTU setting. The default MTU setting can be a pre-defined (e.g., pre-configured) setting for the client device. For example, in some examples, the default MTU setting can be the maximum size of the MTU settings, such as the maximum size of the MTU settings that the client device can use, as described herein. For example, additionally or alternatively, the default MTU setting can be an MTU setting stored at the client device, such as a previously discovered MTU setting according to the techniques described herein.

[0084] In some examples, in response to the confirmation (at 310) that the MTU test was successful, the client device can (at 315) store the default MTU setting as the MTU setting for the socket. The client device can also (at 320) use the stored MTU setting to transmit data via the socket.

[0085] In response to the determination (at 310) that the MTU test has failed, the client device can perform MTU discovery, which may involve performing the operations described herein, such as procedure 100. Figure 1 ) operation and process 200 ( Figure 2 This includes operations such as... In this regard, when probe packets fail to be transmitted successfully using the default MTU setting, the client device can discover the MTU setting of the sockets supported by the connection. As described herein, procedures 100 and 200 can begin by verifying whether the server device is contactable (e.g., by testing the minimum MTU setting). In this regard, if the server device is contactable, procedures 100 and 200 can verify that the failure of the MTU test (at 310) with the default MTU setting is due to the default MTU not being supported (e.g., due to MTU mismatch).

[0086] Figures 4A-4B The diagram illustrates a network path 402A-C connecting client device 405 to various server devices 410A-C (collectively referred to herein as server devices 410, or individually as server devices 410). Figure 4A The diagram illustrates an MTU test using the default MTU settings for each connection between client device 405 and server device 410; while Figure 4B The illustration shows the results of an MTU test for each connection between client device 405 and server device 410, assuming a known MTU setting (e.g., an MTU setting discovered using the enhanced discovery technique described herein).

[0087] Figures 4A-4B Further illustrations show sockets 412A-C (collectively referred to herein as socket 412, or individually as socket 412) with specific MTU settings associated with each connection. Socket A 412A may be associated with a connection between client device 405 and server device 410A, socket B 412B may be associated with a connection between client device 405 and server device 410B, and socket C 412C may be associated with a connection between client device 405 and server device 410C.

[0088] Each socket 412 may include a socket address, which may be a combination of a network destination address and a port number. Packets can be delivered to the correct application, such as an application running at client device 405, based on this socket address. Furthermore, as described herein, the client device can establish socket 412 for a connection when establishing a connection with server device 410. When establishing socket 412, the client device can (e.g., via the socket API) set the MTU settings for socket 412. For example, as... Figure 4A As shown, client device 405 can set the MTU setting for each of sockets A 412A, B 412B, and C 412C to the default MTU setting, such as 1500B as illustrated. Figure 4B As shown, client device 405 can also update the MTU settings for sockets 412A-C based on the MTU settings discovered using the enhanced discovery techniques described herein. In some examples, server devices 410A-C may also include sockets. In this respect, communication between client device 405 and server device 410 may involve transferring packets from a socket at client device 405 to a socket at server device 410, or vice versa.

[0089] As shown in the figure, network path 402 between client device 405 and a given server device 410 may each include several components, such as intermediate devices, VPNs, etc. For example, network path 402A between client device 405 and server device 410A includes gateway device 415, dynamic NAT device 420, and switch device 425. Network path 402B between client device 405 and server device 410B includes gateway device 415 and VPN 430, and network path 402C between client device 405 and server device 410C includes gateway device 415 and switch device 435. While this document illustrates and describes specific combinations of components on network paths, the examples are not limited to this.

[0090] As further shown in the diagram, each component within the network path can have a corresponding MTU, which is labeled "MTU". These MTUs can affect the MTU settings supported by the connection via the network path between client device 405 and server device 410. For example, as Figure 4A As shown, with the default MTU setting (1500 bytes (B)), a packet (such as a probe packet or a data packet) of size 1500 bytes that is transmitted from client device 405 to server device 410A along network path 402A may be dropped, as indicated by error signal 440A. More specifically, this packet may be forwarded by gateway device 415 with an MTU of 1500 bytes, and the packet may successfully reach and be forwarded by dynamic NAT device 420 with an MTU of 1500 bytes. However, switch device 425, which receives the packet from NAT device 420, may not be able to forward the packet to server device 410A because the packet size (1500B) exceeds the MTU (1400B) of switch device 425. Switch device 425 may, for example, drop the packet.

[0091] A 1500-byte packet might also fail to reach server device 410B along network path 402B, as illustrated by error signal 440B. While the packet can be forwarded by gateway device 415, it might not be forwarded at VPN 430. In this regard, although VPN 430 can have an MTU of 1500 bytes, it can add a 50-byte header to the packet. The header added by VPN 430 can be, for example, an IP header used for transmissions through VPN 430, and with this header added, the packet size could be 1550 bytes, exceeding the MTU of VPN 430.

[0092] In some examples, a 1500-byte packet can successfully reach server device 410C along network path 402C. In this respect, both gateway device 415 and switch device 435 can forward the packet along network path 402C. In some examples, because the packet size exceeds the 1300-byte MTU of switch device 435, switch device 435 may discard the packet, similar to what is described with respect to switch device 425. However, as shown, in some examples, switch device 435 can segment the packet (e.g., perform packet fragmentation) to forward the packet to server device 410C. In this respect, switch device 435 can split the packet into multiple smaller packets, such as a first packet of 1300 bytes and a second packet of 200 bytes. Server device 410C can reassemble the first and second packets to receive the packet.

[0093] In some examples, switch device 435 may perform packet fragmentation based on its own capabilities, rather than discarding packets. For example, in some examples, switch device 435 may be able to perform packet fragmentation, while switch device 425 may lack this capability and therefore may discard packets (as indicated by error signal 440A). Additionally or alternatively, switch device 435 may perform packet fragmentation based on the packet itself. For example, client device 405 may transmit packets with the DF flag set to a first value (which may indicate that packet fragmentation is permitted) to server device 410C. In contrast, client device 405 may transmit packets with the DF flag set to a second value (which may indicate that packet fragmentation is not permitted) to server device 410A.

[0094] Go to Figure 4BUsing the techniques described herein, client device 405 can discover the MTU setting of each socket 412A-C associated with a corresponding connection between client device 405 and server device 410. In some examples, client device 405 can perform MTU discovery to identify the MTU setting of socket 412A associated with a connection to server device 410A based on a packet of size 1500 bytes (e.g., transmitted using the default MTU setting) failing to reach server device 410A. Similarly, client device 405 can perform MTU discovery to identify the MTU setting of socket 412B associated with a connection to server device 410B based on a packet of size 1500 bytes (e.g., transmitted using the default MTU setting) failing to reach server device 410B.

[0095] As an illustrative example, for socket 412A, client device 405 can discover an MTU setting of 1400 bytes. A packet of the corresponding size transmitted by client device 405 to server device 410A can be successfully received at server device 410A because the packet size is no larger than the MTU of any device in network path 402A. Therefore, gateway device 415, dynamic NAT device 420, and switch device 425 can each forward the packet so that it reaches server device 410A.

[0096] As another illustrative example, for socket 412B, client device 405 can discover a 1450-byte MTU setting. As shown, gateway device 415 can forward the 1450-byte packet to VPN 430, and VPN 430 can add a 50-byte header to the packet, resulting in a 1500-byte packet being forwarded to server device 410B.

[0097] Upon discovering these MTU settings, client device 405 can perform multiple MTU tests using various sizes as MTU settings (e.g., transmitting packet probes of various sizes). As an illustrative example, for socket 412A, client device 405 can test the minimum MTU setting to verify whether server device 410A is contactable, as referenced herein. Figure 1As described in Task 105. Using an MTU test in the minimum MTU case, client device 405 can determine that the dropping of packets of size 1500 bytes is due to an MTU mismatch (here, a problem with switch device 425), rather than due to downtime experienced by server device 410A. Client device 405 can then test various MTU settings(s) to discover the MTU setting. In some examples, client device 405 can start with the largest MTU setting size (e.g., it could be the default MTU setting (here, 1500 bytes)) and can change the test MTU setting size to discover the MTU setting. For example, client device 405 can test an MTU setting of size 1500 bytes and reduce the MTU setting size by 5 bytes, 10 bytes, 100 bytes, etc., to discover the MTU setting of 1400B illustrated. The client device can identify the 1400-byte probe packet as the size for MTU setting based on the successful reception of the probe packet at server device 410A (e.g., based on the response to the probe packet from server device 410A). Furthermore, by using a transport layer (e.g., using socket 412A) to transmit the probe packet to the network destination address and port number of server device 410A, the client device can also ensure that the packet reaches server device 410A itself, rather than being stopped at dynamic NAT device 420.

[0098] The client device can also identify the 1400 bytes as the size for MTU setting based on the uninterrupted runtime experienced by the server device 410A. For example, the client device 405 can compare the runtime identifier received in response to a 1400-byte probe packet with a previously received runtime identifier (such as the runtime identifier received in response to a probe with the minimum MTU setting size) to verify whether the server device 410A maintained uninterrupted runtime during the MTU setting discovery period.

[0099] In some examples, client device 405 can successfully reach server device 410C with packets of size 1500 bytes (e.g., transmitted using the default MTU setting), thus avoiding an MTU discovery for socket 412C. For example, the client device could instead store the default MTU setting as the MTU setting for the connection to server device 410C and use that stored MTU setting to transmit data, as in tasks 315-320. Figure 3As described above. In other examples, even if a packet has been successfully transmitted to server device 410C, client device 405 may perform MTU discovery to determine whether an MTU setting with a larger size is available for socket 412C. For example, in some examples, the default MTU setting may not be the maximum MTU setting available for client device 405. In this case, client device 405 may continue to perform MTU discovery to determine whether a larger size can be used for that MTU setting.

[0100] When the MTU setting for socket 412A is identified as 1400 bytes, client device 405 can remain unaware of the components on network path 402A. Similarly, when the MTU setting for socket 412B is identified as 1450 bytes, client device 405 can remain unaware of the components on network path 402B; and when the MTU setting for socket 412C is identified as 1500 bytes, client device 405 can remain unaware of the components on network path 402C. In this respect, regardless of which components are included in the network path, client device 405 can determine the MTU setting for the socket based on the successful transmission of probe packets and the receipt of corresponding responses. Therefore, even if these paths include different components, client device 405 can use the techniques described herein on each of the network paths 402A-C.

[0101] Figure 5 This is a flowchart of a process 500 for discovering the MTU settings of sockets associated with a connection between a client device and a server device, based on some examples. Although Figure 5 The diagram illustrates tasks executed in a given order, but these tasks can be executed in a different order, some tasks can be omitted, and additional tasks can be added. Examples of client devices may include... Figure 2 Client device 205, client device 405 in Figure 4, Figure 6 Computing devices such as the 600. Examples of server devices may include... Figure 2 Server device 210, server device 410 in Figure 4, Figure 6 Computing devices such as the 600 series.

[0102] Process 500 includes (at 505) transmitting a probe packet from the client device to the server device via a socket in response to receiving a first runtime identifier from the server device. The probe packet may have a size and may include a request for the runtime identifier. In some examples, the first runtime identifier may indicate that the server device is contactable (e.g., the server device is experiencing runtime and is reachable via the network).

[0103] In some examples, process 500 may also involve: a client device transmitting a first probe packet (different from the probe packet) to a server device via a socket. The first probe packet may have a first size and may include an additional request for a runtime identifier. Process 500 may also involve: a client device receiving a first response to the first probe packet from the server device via a socket, and the first response may include the first runtime identifier. In this respect, in some examples, the client device may transmit the first probe packet (and receive the first response with the first runtime identifier) ​​before transmitting the probe packet. In some examples, the first size may be the minimum size of the MTU setting for the socket. This minimum size may be a size defined by the network protocol used to transmit the probe packet, such as 576 bytes for IPv4, 1280 bytes for IPv6, etc. In this respect, the first probe packet may test the minimum MTU setting for the socket. As described herein, the client device may test the minimum MTU setting (e.g., perform an MTU test in the case of the minimum MTU setting, such as...). Figure 1 As described in Task 105, to verify whether the server device is reachable and / or is undergoing runtime.

[0104] In some examples, in process 500, the client device may transmit a first probe packet in response to determining a set of runtime identifiers received from the server device that identifies the runtime of an interruption of the server device. In some examples, the runtime may be interrupted by a downtime. For example, as... Figure 1 As described in Task 145, in response to determining a mismatch in the set of runtime identifiers received from the server device, the client device can verify whether the server device is experiencing runtime by performing an MTU test with the minimum MTU setting.

[0105] In some examples, process 500 may involve the client device transmitting an additional probe packet in response to transmitting the additional probe packet and determining that the additional probe packet was not successfully received at the server device. The client device may transmit the additional probe packet to the server device via a socket. The additional probe packet may have an additional size, which may be larger than the size of the probe packet. In this respect, the client device may test multiple MTU settings. For example, as described in tasks 125-140, the client device may test an MTU setting with a specific size, determine that the MTU test was unsuccessful, change the size of the MTU setting to be tested, and perform an MTU test at the changed MTU setting size.

[0106] In some examples, the additional size can be the maximum size of the MTU setting used for the socket. In some examples, the maximum size can be defined based on the capabilities of the client device. In some examples, the client device can determine that the additional probe packet was not successfully received based on the absence of an additional response to the additional probe packet (this could include not receiving the additional response at all or not receiving the additional response within the timeout period).

[0107] In some examples, the client device may transmit additional probe packets in response to completing a handshake with the server device (such as a TCP handshake, TLS handshake, etc.). The client device may determine that the additional probe packets were not successfully received at the server device based on the incomplete handshake with the server device, such as... Figure 2 As described in Task 220.

[0108] In some examples, the client device may transmit probe packets in response to setting the size of the socket's MTU setting. Setting the size of the socket's MTU setting may involve setting the socket's MSS based on that size. In some examples, the client device may use the socket API to set the MSS.

[0109] In some examples, probe packets include a DF flag, and the client device can transmit probe packets with the DF flag set to a first value to allow for packet fragmentation of the probe packets.

[0110] Process 500 includes (at 510) the client device receiving a response to the probe packet from the server device via a socket. This response may indicate that the probe packet has been successfully received at the server device and may include a second runtime identifier.

[0111] Process 500 includes (at 515) the client device storing the size as the maximum transmission unit (MTU) setting of the socket. In response to determining a first runtime identifier and a second runtime identifier that identify the uninterrupted runtime of the server device, the client device may store the size as the MTU setting of the socket.

[0112] The client device can determine the uninterrupted runtime of the server device based on a comparison of a first runtime identifier and a second runtime identifier, for example, as per the context of... Figure 1 As described in Task 145.

[0113] Process 500 includes (at 520) the transmission of data packets from the client device to the server device via a socket using the MTU setting.

[0114] Figure 6This is a block diagram of a computing device 600, based on some examples, capable of discovering the MTU settings of sockets associated with connections between computing devices and server devices. The computing device 600 includes processing resources 610, memory 615, and a machine-readable storage medium 620 including instructions 625, 630, 635, 640, 645, and 650 (collectively referred to below as instructions 625-650) for discovering the MTU settings. The computing device 600 can be, for example, a server, client computer, laptop computer, tablet computing device, portable reading device, wireless email device, mobile phone, or any other computing device. Furthermore, the computing device 600 can be an example of a client device described herein (e.g., Figure 2 Client device 205 in Figure 2, client device 405 in Figure 4, etc.). In some examples, computing device 600 may be an example of the server device described herein (e.g., Figure 2 (e.g., server device 210 in Figure 2, server device 410 in Figure 4). In this respect, although some operations are described as being performed by either the client device or the server device, the operations can be performed by the client device, the server device alone, or a combination of both.

[0115] The probe packet transmission command 625 can be executed to transmit a probe packet to the server device via a socket in response to receiving a first runtime identifier from the server device. The probe packet may have a size and may include a request for the runtime identifier.

[0116] In some examples, the machine-readable storage medium 620 may also include instructions that can be executed to: transmit a first probe packet (different from the probe packet) to the server device, wherein the first probe packet has a first size. The first size may be a default MTU setting size, which may be a predetermined size, as per [reference to MTU settings]. Figure 3 As described in task 305. In other examples, the first size can be the minimum size set by the MTU. The instruction can also be executed to transmit a second probe packet in response to determining that the first probe packet was not successfully received at the server device, as per [the description of task 305]. Figure 3 As described in tasks 310-325. In some examples, the instructions can also be executed to: transmit a second probe packet in response to a predetermined delay after the transmission of the first probe packet has elapsed, as per [the relevant instructions]. Figure 1 As described in task 115. The instructions can also be executed to: receive a second response to the second probe packet from the server device. In some examples, the second response may include a first runtime identifier. In this respect, in some examples, the client device may transmit the first and second probe packets before transmitting the probe packet.

[0117] The receive response instruction 630 can be executed to receive a response to the probe packet from the server device via a socket. This response may include a second runtime identifier.

[0118] The stored MTU setting instruction 635 may include a determine probe packet received instruction 640 and a determine uninterrupted runtime instruction 645. In some examples, the stored MTU setting instruction 635 may be executed to: in response to executing the determine probe packet received instruction 640 and the determine uninterrupted runtime instruction 645, store the size as the socket's MTU setting. Storing the size as the socket's MTU setting may involve storing the size in memory 615, which may be a cache, memory, storage device, etc. Although illustrated separately, in some examples, a machine-readable storage medium 620 may include memory 615. Therefore, storing the size as the socket's MTU setting may involve storing the size in a machine-readable storage medium 620.

[0119] The instruction 640 to determine that the probe packet has been received can be executed to determine that the probe packet has been successfully received at the server device, and the instruction 645 to determine the uninterrupted runtime can be executed to determine the uninterrupted runtime of the server device by a first runtime identifier and a second runtime identifier.

[0120] In some examples, the determine probe packet received instruction 640 can also be executed to determine that the probe packet has been successfully received at the server device based on a comparison of the probe packet's content with the response's content. For example, the client device can compare the probe packet's pattern with the response's pattern. The client device can additionally or alternatively compare the probe packet's content with the response's content to determine whether the server device has covered the entire content of the probe packet. The determine probe packet received instruction 640 can also be executed to determine that the probe packet has been successfully received at the server device based on a comparison of the probe packet's size with the response's size.

[0121] The Transmit Data Packet Command 650 can be executed to transmit data packets to the server device via a socket using the MTU setting.

[0122] Processing resource 610 may include a collection of hardware processors. The hardware processors may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry. Processing resource 610 may retrieve, decode, and execute instructions 625-650 to discover the MTU setting. As an alternative or supplement to retrieving and executing instructions, processing resource 610 may include at least one integrated circuit (IC), other control logic, other electronic circuitry, or combinations thereof, including several electronic components for performing the functions of instructions 625-650.

[0123] As described in detail herein, the machine-readable storage medium 620 may be encoded with a series of executable instructions, including instructions 625-650. The machine-readable storage medium 620 may be encoded with executable instructions to perform... Figure 1 The process described in 100 Figure 2 The process described in 200 Figure 3 The process described in 300 Figure 5 The process described in 500 Figure 7 The instructions 705-725 described herein, and / or any other operations performed by the client device or server device, are permitted, but do not limit the scope of this disclosure.

[0124] Figure 7 This is a block diagram of a machine-readable storage medium 700 with instructions for discovering the MTU setting for a socket, based on some examples. The machine-readable storage medium 700 includes instructions 705, 710, 715, 720, and 725 (collectively referred to below as instructions 705-725). The machine-readable storage medium 700 may be included in a client device (e.g., Figure 2 Client device 205, client device 405 in Figure 4, Figure 6 Instructions 705-725, as described herein, are executed in or by a computing device 600, etc., and / or by a client device.

[0125] The MTU setting instruction 705 can be executed by at least one processing resource to: in response to receiving a first runtime identifier from a server device, set the size of the maximum transmission unit (MTU) setting of the socket.

[0126] The probe packet transmission instruction 710 can be executed by at least one processing resource to transmit a probe packet to a server device via a socket. The probe packet may have a size and may include a request for a runtime identifier.

[0127] In some examples, the probe packet transmission command 710 can also be executed to transmit probe packets to a server via a network path associated with the socket. This network path may include a dynamic network address translation device and / or a virtual private network.

[0128] The receive response instruction 715 can be executed by at least one processing resource to: receive a response to the probe packet from the server device via a socket. The response may indicate that the probe packet has been successfully received at the server device and may include a second runtime identifier.

[0129] The storage MTU setting instruction 720 can be executed by at least one processing resource to: in response to determining a first runtime identifier and a second runtime identifier to identify the uninterrupted runtime of the server device, store the size as the MTU setting of the socket.

[0130] In some examples, the Store MTU Setting instruction 720 can also be executed to store the MTU setting, with the size as the socket, in a cache associated with the socket. Examples of a cache may include... Figure 6 The memory 615 and / or the machine-readable storage medium 700.

[0131] The data packet transmission instruction 725 can be executed by at least one processing resource to transmit data packets to a server device via a socket using an MTU setting.

[0132] As described in detail herein, the machine-readable storage medium 700 may be encoded with a series of executable instructions, including instructions 705-725. The machine-readable storage medium 700 may be encoded with executable instructions to perform... Figure 1 The process described in 100 Figure 2 The process described in 200 Figure 3 The operation of process 300 described herein, and / or by a client device (e.g., Figure 2 Client device 205, client device 405 in Figure 4, Figure 6 Any other operation performed by the computing device 600, etc., but it does not limit the scope of this disclosure.

[0133] Storage media in which machine-readable instructions are stored (e.g., Figure 6 620 or Figure 7The 700 in the definition can include any one or a combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory; magnetic disks, such as fixed disks, floppy disks, and removable disks; other magnetic media, including magnetic tape; optical media, such as optical discs (CDs) or digital video discs (DVDs); or other types of storage devices. Thus, machine-readable storage medium 620 ( Figure 6 ) and machine-readable storage medium 700 ( Figure 7 The instructions can be non-transient. It is important to note that the instructions discussed above can be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. One or more such computer-readable or machine-readable storage media are considered part of an article (or artifact). An article or artifact can refer to any manufactured single component or multiple components. One or more storage media can be located in a machine that executes the machine-readable instructions, or at a remote site from which machine-readable instructions can be downloaded for execution via a network.

[0134] In this disclosure, unless the context clearly indicates otherwise, the use of the terms “a,” “an,” or “the” is intended to include the plural form as well. Furthermore, the terms “includes,” “comprises,” or “have,” as used in this disclosure, specify the presence of the stated element but do not exclude the presence or addition of other elements.

[0135] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, some implementations may be practiced without some of these details. Other implementations may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A method comprising: In response to receiving a first runtime identifier from a server device, a client device transmits a probe packet to the server device via a socket, the probe packet having a size and including a request for the runtime identifier; The client device receives a response to the probe packet from the server device via the socket. The response indicates that the probe packet has been successfully received at the server device and includes a second runtime identifier. In response to determining that the first runtime identifier and the second runtime identifier identify the uninterrupted runtime of the server device, the client device stores the size as the maximum transmission unit (MTU) setting of the socket; as well as The client device transmits data packets to the server device via the socket using the MTU setting.

2. The method according to claim 1, further comprising: The client device transmits a first probe packet to the server device via the socket. The first probe packet has a first size and includes an additional request for a runtime identifier. as well as The client device receives a first response to the first probe packet from the server device via the socket, the first response including the first runtime identifier.

3. The method of claim 2, wherein the first size is the minimum size set for the MTU of the socket.

4. The method according to claim 2, further comprising: In response to determining that a set of runtime identifiers received from the server device identifies the runtime of an interruption of the server device, the client device transmits the first probe packet.

5. The method according to claim 1, comprising: The client device further transmits the probe packet in response to the following operations: The client device transmits an additional probe packet to the server device via the socket, the additional probe packet having an additional size larger than the stated size; as well as The client device determines that the additional probe packet was not successfully received at the server device.

6. The method according to claim 5, further comprising: The client device determines that the additional probe packet was not successfully received at the server device based on the fact that it did not receive an additional response to the additional probe packet.

7. The method according to claim 5, further comprising: In response to completing the handshake with the server device, the client device transmits the additional probe packet; as well as Based on the incomplete handshake with the server device, the client device determines that the additional probe packet was not successfully received at the server device.

8. The method of claim 5, wherein the additional dimension is the maximum dimension set for the MTU of the socket.

9. The method according to claim 1, further comprising: The probe packet is also transmitted by the client device in response to setting the MTU setting of the socket to the size.

10. The method of claim 9, further comprising: The client device sets the MTU setting of the socket to the specified size based on the maximum segment size of the socket set according to the specified size.

11. The method of claim 1, wherein the probe packet includes a "non-fragmented" DF flag, and wherein transmitting the probe packet includes: The client device transmits the probe packet having the DF flag set to a first value, thereby allowing packet segmentation of the probe packet.

12. A system comprising: At least one processing resource; as well as A non-transient machine-readable storage medium including instructions executable by the at least one processing resource to: In response to receiving a first runtime identifier from a server device, a probe packet is transmitted to the server device via a socket, the probe packet having a size and including a request for the runtime identifier; Receive a response to the probe packet from the server device via the socket, the response including a second runtime identifier; The size is stored as the maximum transmission unit (MTU) setting of the socket in response to the following operations: It has been confirmed that the probe packet has been successfully received at the server device; as well as The first runtime identifier and the second runtime identifier are determined to identify the uninterrupted runtime of the server device; as well as Data packets are transmitted to the server device via the socket using the MTU setting.

13. The system of claim 12, wherein the instructions may further be executed to: The probe packet has been successfully received at the server device based on one or more of the following: The comparison between the content of the probe packet and the content of the response; and A comparison of the size with the size of the response.

14. The system of claim 12, wherein the instructions may further be executed to: Transmit a first probe packet of a first size to the server device; In response to determining that the first probe packet was not successfully received at the server device, a second probe packet is transmitted; and The server device receives a second response to the second probe packet, the second response including the first runtime identifier.

15. The system of claim 14, wherein the first dimension is the default MTU setting dimension.

16. The system of claim 14, wherein the instructions are further executable to: The second probe packet is transmitted in response to a predetermined delay following the elapsed transmission of the first probe packet.

17. A non-transient machine-readable storage medium comprising instructions executable by at least one processing resource of a computing device to: In response to receiving a first runtime identifier from the server device, the size of the maximum transmission unit (MTU) setting of the socket is set. A probe packet having the stated size and including a request for a runtime identifier is transmitted to the server device via the socket. Receive a response to the probe packet from the server device via the socket, the response indicating that the probe packet has been successfully received at the server device and including a second runtime identifier; In response to determining that the first runtime identifier and the second runtime identifier identify the uninterrupted runtime of the server device, the size is stored as the MTU setting of the socket; as well as Data packets are transmitted to the server device via the socket using the MTU setting.

18. The non-transient machine-readable storage medium of claim 17, wherein the instructions are further executable to: The size is stored as the MTU setting of the socket in the cache associated with the socket.

19. The non-transient machine-readable storage medium of claim 17, wherein the instructions are further executable to: The probe packets are transmitted to the server via a network path associated with the socket, the network path including a dynamic network address translation device.

20. The non-transient machine-readable storage medium of claim 17, wherein the instructions are further executable to: The probe packets are transmitted to the server via a network path associated with the socket, the network path including a virtual private network.

Images