Browse Prior Art Database

Reasoning the cause of network error in application layer upon the network stack

IP.com Disclosure Number: IPCOM000019565D
Original Publication Date: 2003-Sep-19
Included in the Prior Art Database: 2003-Sep-19
Document File: 5 page(s) / 91K

Publishing Venue

IBM

Abstract

This method enables the pluggable application upon service proxy system to reason the cause of network error. The pluggable application can take proper action against the errors by finding out about the error. If a network error occurs when proxy server is sending a request to Web server, the response time of this request becomes longer due to the error recovery by network layer i.e. TCP, UDP layer. If a large number of error retries for popular sites happens, it consumes available HTTP connection resource of this proxy server. Service proxy can avoid this catastrophic situation, if pluggable application can inspect the error in detail, and proper recovery actions are taken.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 5

Reasoning the cause of network error in application layer upon the network stack

  Disclosed is a way to reason the cause of network error in application layer upon the network stack.

This method enables the pluggable application upon service proxy system to reason the cause of network error. The pluggable application can take proper action against the errors by finding out about the error.

 If a network error occurs when proxy server is sending a request to Web server, the response time of this request becomes longer due to the error recovery by network layer i.e. TCP, UDP layer. If a large number of error retries for popular sites happens, it consumes available HTTP connection resource of this proxy server. Service proxy can avoid this catastrophic situation, if pluggable application can inspect the error in detail, and proper recovery actions are taken.

1. Background and Problem

The performance bottleneck of whole internet is moving from the network layer to the servers, as a lot of research works have been devoted to network congestion control. The contribution to congestion control in TCP or IP Protocol layer[1][2] has been reported. The proxy servers are providing various services; Caching, Filtering, Contents Adaptation services. Service application can be added into Proxy Server, c.f. Open Pluggable Edge Server (OPES)[3] as a pluggable executable component. The level of services becomes higher, richer and complicated, the service proxies can easily be bottleneck of the whole networks. It becomes more important to manage service proxy's throughput to control whole network throughput. Service Proxies are built upon the network protocol stack as shown in Figure-1. In addition to that, pluggable service application is built upon middleware which is a framework to be designed to easily develop the pluggable functional components.

Pluggable Service Application

  Client Application

Service Proxy (Appl. Layer)

 Server Application

HTTP, FTP,etc

HTTP, FTP ,etc

HTTP, FTP, etc

HTTP, FTP ,etc

Application

    Transport Network

TCP

TCP/UDP

TCP

IP

IP

IP

Ethernet Driver

Ethernet Driver

Ethernet Driver

Client Service Proxy Content Server

Figure-1. Service Application on Layered Network Stack

As far as HTTP protocol [4] based application, if TCP layer in the service proxy server does not receive ACK packet from Web Server to replay SYN packet which TCP layer has sent to Web server in order to send a request, when TCP layer resends SYN packets until error recovery timeout. As for DNS (Domain Name System), DNS resends a UDP data packet for error recovery too. Application layer is kept waiting for the response until this recovery has been completed in success or fail in TCP or UDP layer. The service application may only get HTTP error result of HTTP 504 Gateway Timeout response.

[This page contains 3 pictures or other non-text objects]

Page 2 of 5

 The elapsed time of error recovery depends on TCP/IP or other network configuration setting[5][6], i.e. re...