Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Efficiently polling a DMA module to determine if the DMA copying of a packet payload to an application buffer is complete. For communication packets received from a network, a processing module may be configured to poll the DMA module at times when it is likely that the DMA copying of packet payloads is complete. Packets may be received and processed in batches. The polling of the DMA module for a packet belonging to a first batch may be deferred until the processing of a next batch. An exception may occur if a predefined amount of time elapses following the completion of the processing of the first batch before the next batch is received. In response to the predefined amount of time elapsing before the receipt of the next batch, the DMA module may be polled, i.e., prior to the next batch being processed.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: A method for the synchronization of network neighbor reachability between a host networking stack and a peripheral device, which offloads one or more network protocols is provided. The network neighbor reachability represents the reachability of another computer on the network. This invention enables conventional neighbor reachability to be extended to seamlessly support some network connections to a specific remote host to be offloaded to a peripheral device, while other network connections are not.

Abstract: Disclosed is a method for slowing down the spread of viruses by limiting the number of Transmission Control Protocol (“TCP”) connection attempts to arbitrary Internet Protocol (“IP”) addresses that can be in progress at any given time—a common method employed by viruses to spread to other hosts from an infected host. This is achieved by setting a small limit on the number of connection attempt requests that can be in progress at any given time and can be implemented regardless of whether anti-virus software is installed on the system.

Abstract: The invention provides mechanisms for transferring processor control of secure Internet Protocol (IPSec) security association (SA) functions between a host and a target processing devices of a computerized system, such as processors in a host CPU and a NIC. In one aspect of the invention, the computation associated with authentication and/or encryption is offloaded while the host maintains control of when SA functions are offloaded, uploaded, invalidated, and re-keyed. The devices coordinate to maintain metrics for the SA, including support for both soft and hard limits on SA expiration. Timer requirements are minimized for the target. The offloaded SA function may be embedded in other offloaded state objects of intermediate software layers of a network stack.

Abstract: Techniques are provided for adjusting to changes to the latency for a connection between two nodes on a network. In accordance with some embodiments, when a transmitting node encounters a retransmission timeout for a packet sent to a receiving node, the latency for the connection is newly measured and used to calculate a new retransmission timeout period for subsequent transmissions by the transmitting node. In some embodiments, the latency is not newly measured if a selective acknowledgement is received indicating that congestion on the network is only temporary.

Abstract: Creating different congestion control modules (CCMs) that can be plugged into a network communications stack (e.g., a TCP/IP stack). Software abstractions defining transport control events, congestion control algorithms and other information may be exposed by an application programming interface, e.g., of an operating system, and these abstractions may be used to define a CCM. The network communications stack may be configured to select one of multiple available CCMs to control congestion for a given connection. This selection may be based on any of a variety of factors including, but not limited to: network environment; connection path characteristics; connection link characteristics; a value of a socket parameter of an application; other factors; and any suitable combination of the foregoing. Thus, CCMs may be selected and implemented on a per-connection basis.

Abstract: A new method and framework for scheduling receive-side processing of data streams received from a remote requesting client by a multiprocessor system computer is disclosed. The method receives data packets from the remote requesting client via a network and, for each data packet, applies a cryptographically secure hashing function to portions of the received data packet yielding a hash value. The method further applies the hash value to a processor selection policy to identify a processor in the multiprocessor system as a selected processor to perform receive-side processing of the data packet. The method queues the received data packet for processing by the selected processor and invokes a procedure call to initiate processing of the data packet.

Abstract: A computer system with black hole management. The black hole management system shares black hole status information among connections that employ the same path. The black hole status information may indicate either that a black hole exists on the path or that communications have been performed successfully on the path, indicating that no black hole exists. By sharing this information, delays in transmission caused by black hole probing may be reduced. Additionally, status information for a connection is reset when information indicates that the connection has been altered. By resetting the status information, delays in transmission associated with sending reduced sized packets over connections for which black holes were previously detected but may have been eliminated by changes in the connection, are avoided.

Abstract: Malicious network node activity and, in particular, denial of service attacks, may be mitigated by one or more practical mitigation mechanisms and mitigation mechanism combinations. Suitable protocol messages may be challenged with a challenge probe. A response to the challenge probe may be utilized to determine if received protocol messages are illegitimate, that is, originated by a malicious network node. Received protocol messages may be classified as questionable protocol messages. For efficiency, protocol message challenges may be limited to protocol message classified as questionable. A sequence number limit may be calculated as a function of receive window size. Transmission control protocol messages may be determined to be illegitimate by comparing the acknowledgement number field with the calculated sequence number limit.

Abstract: In an exemplary device implementation, a device includes: a connection migrator that is configured to migrate connections away from the device; the connection migrator capable of precipitating a compilation of protocol state for a connection across a protocol stack; the connection migrator adapted to aggregate the compiled protocol state with data for the connection into an aggregated connection state; the connection migrator further capable of causing the aggregated connection state to be sent toward a target device. In an exemplary media implementation, processor-executable instructions direct a device to perform actions including: obtaining at least a portion of a source/destination pair from a packet; accessing an encapsulation mapping table using the at least a portion of the source/destination pair to locate an encapsulation mapping entry; extracting a flow identifier from the encapsulation mapping entry; and replacing part of the packet with the flow identifier to produce an encapsulated packet.

Abstract: The present invention provides mechanisms for transferring processor control of multiple network connections between two component devices of a computerized system, such as between a host CPU and a NIC. In one aspect of the invention, two or more network communications may each have a different state object in the upper layers of a network protocol stack, and have a common state object in the lower layers (e.g., the Framing Layer) of the network protocol stack. In part due to the commonalities in the lower software layer states, the invention provides for offloading processor control of multiple network communications at once, including long and short-lived connections. In addition, the invention can negotiate with an alternative peripheral device to offload the network communication to the alternative peripheral device in the event of a failover event, and provides a solution to incoming data packets destined for one or more VLANs.