Citrix Systems, Inc.

Ashok Kumar Jagadeeswaran

Saravana Annamalaisami

Saravanakumar Annamalaisami

Roy Rajan

Rajesh Joshi

Ramanjaneyulu Y Talla

Mahesh Mylarappa

Jyotheesh Rao Kurma

Mohit Prakash Saxena

Krishna Khanal

Systems and methods of propagating maximum segment size and path maximum transmission unit of network paths between an intermediary device of a cluster with a plurality of destinations are described. A first core of a node including multiple cores and intermediary to a client and a plurality of servers may receive a response to a packet transmitted to a destination indicating that the packet has a size greater than a MTU of a network path between the node and a destination. The first core identifies the MTU of the network path and determines that the identified MTU is different than an MTU used by the first core. The first core replaces the MTU stored in an entry corresponding to the destination in a PMTU table maintained with the identified MTU. The first core transmits, to other cores of the node, the identified MTU to update each core's PMTU table.

Systems and methods for synchronizing MSS and PMTU in Ncore and cluster systems

The virtual Server (vServer) of an intermediary device deployed between a plurality of clients and services supports parameters for setting maximum segment size (MSS) on a per vServer/service basis and for automatically learning the MSS among the back-end services. In case of vServer/service setting, all vServers will use the MSS value set through the parameter for the MSS value set in TCP SYN+ACK to clients. In the case of learning mode, the backend service MSS will be learnt through monitor probing. The vServer will monitor and learn the MSS that is being frequently used by the services. When the learning is active, the intermediary device may keep statistics of the MSS of backend services picked up during load balancing decisions and once an interval timer expires, the MSS value may be picked by a majority and set on the vServer. If there is no majority, then the highest MSS is picked up to be set on the vServer.

Systems and methods for learning MSS of services

The present disclosure is directed towards a system and method for providing a SPDY to HTTP gateway via a device intermediary to a plurality of clients and a server. An NPN handshake by the intermediary device may establish SPDY support. The intermediary device may receive and process one or more control frames via SPDY session with the client. The intermediary device may generate and transmit HTTP communication to server corresponding to SPDY control frames. The intermediary device may receive and process one or more HTTP responses from server. The intermediary device may generate and transmit SPDY communication via SPDY session to client corresponding to HTTP response.

Systems and methods for a SPDY to HTTP gateway

The present disclosure presents systems and methods for maintaining identification of network devices sending or traversing a network packet en route to an intermediary device deployed between a source and a destination network device. An intermediary may receive an acknowledgement packet comprising an option field identified by an option number for a transport layer connection established via the intermediary, comprising overlay network data that identifies IP addresses of the originating network device and host network devices intercepting and forwarding the network packet to the intermediary, and may determine the option number for the option field from which to obtain the overlay network data identifying IP addresses. The intermediary device may receive a second request of the client to access the server via the transport layer connection and insert IP addresses from the overlay network data into an application layer protocol header of the second request forwarded to the server.

Systems and methods for client IP address insertion via TCP options

Described herein is a method and system for preventing Denial of Service (DoS) attacks. An intermediary device is deployed between clients and servers. The device receives a first packet of an application layer transaction via a transport layer connection between the device and client. The device records a last activity time for the transport layer connection based upon the timestamp of the first packet. The device receives subsequent data packets and determines whether the data in the packets completes a protocol data structure of the application layer protocol. If the device determines that the subsequent packet completes the protocol data structure, the last activity time is updated. If the device determines that the application layer protocol remains incomplete, the device retains the last activity time and determines that the duration of inactivity for the transport layer connection exceeds a predetermined threshold. The device may subsequently drop the connection.

Systems and methods for detecting incomplete requests, TCP timeouts and application timeouts

The present solution is directed to a system for handling network interface card (NIC) congestion by a NIC aware application. The system may include a device having a plurality of network interface cards (NICs), a transmission queue corresponding to a NIC of the plurality of NICs; and an overflow queue for storing packets for the NIC when congested. The system may also include an application executing on the device outputting a plurality of packets to the transmission queue responsive to detecting that the NIC is identified as not congested. The device identifies the NIC as congested responsive to determining that a number of packets stored in the transmission queue has reached a predetermined threshold and responsive to detecting identification of the NIC as congested, the application stores one or more packets to the overflow queue. The device transmits one or more of the plurality of packets stored in the transmission queue and transmits a predetermined number of packets from the overflow queue.

Systems and methods for handling NIC congestion via NIC aware application

The present application presents systems and methods for handling by an HTTP virtual server (HTTPVS), connections via which non-HTTP data is transmitted between clients and servers. HTTPVS intercepts a request from a client to establish first transport layer connection (TLC) with a server. HTTPVS establishes second TLC with the servers in response to receiving an acknowledgment from a client to establish the first TLC. HTTPVS determines if a first network packet transmitted via first TLC comprises an HTTP payload or non-HTTP payload. If HTTPVP the first network packet includes HTTP payload, HTTPVS may process all transmissions from the first TLC in accordance with connection tracking and forward the processed transmissions to the server via the second TLC. If HTTPVS determines that the first network packet does not include an HTTP payload, HTTPVS may link the first TLC and the second TLC so the client and server exchange non-HTTP communication without interruption.

Growing community of inventors

Karnataka, India

Ashok Kumar Jagadeeswaran