Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
2000-03-29
2004-06-22
Dinh, Dung C. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C719S328000, C709S245000
Reexamination Certificate
active
06754709
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to network address translation and proxy application control of network communication and, more particularly, relates to the combination of network address translation and proxy application functionality into a transparent application gateway process.
BACKGROUND OF THE INVENTION
As the number of computers that needed or wanted to be connected to the Internet continued to grow, it soon became obvious that this number could not be accommodated by the number of available IP addresses, known as dotted-quads. In response to this address depletion problem, a method as illustrated in
FIG. 2
was devised whereby a number of computers C
1
, C
2
, etc. could be located on a “private” network
60
and would use private IP addresses
62
to communicate with each other. These private IP addresses could be reused on other private networks since no one outside the private network could see these addresses. In order to allow the computers on the private network to communicate with other computes S
1
, S
2
, etc. on a public network, such as the Internet
64
, the private network utilizes one machine
66
to provide the gateway for all of the computers on the private network to reach the public network. Through the use of the private addresses
62
on the private network
60
and the gateway computer
66
, the address depletion problem is at least slowed.
This gateway computer
66
runs a program called a network address translator (NAT) that has both a private IP address
62
and a public IP address
68
. As computers on the private network attempt to establish sessions with a server on a public network (or another private network), the NAT changes the source address
70
of the message packets
72
from the private address of the client computer to its public IP address. In this way, the private IP address is not communicated on the public network. The messages all appear to have come from the public IP address of the NAT machine. The NAT maintains a mapping
74
of the translation from the private to the public IP address so that when messages are received from the public network in response as illustrated by line
76
, the NAT can forward them to the proper client machine. This operation of the NAT is completely transparent to the client computers on the private network, i.e. they each believe that they are communicating directly with the public servers.
FIG. 3
illustrates this redirect capability of the NAT machine. Specifically, a client machine C
1
attempts to establish a session
78
directly with public server S
1
as indicated by dashed line
80
. However, when the message from C
1
is detected by the NAT
66
, it dynamically redirects
82
the message to S
1
and changes the source address as described above. The client process does not know that the NAT has changed its messages' source address, and continues to believe that it is communicating directly with the public server. Messages from the server S
1
are dynamically redirected
82
to the client C
1
based on the mapping of the address translation. As may be seen from
FIG. 4
, this address translation takes place at a low level, e.g. at the kernel level
84
in a Window's architecture.
While the NAT has greatly alleviated the address depletion problem, especially for home and small business networks, its translation of source addresses is fixed within its programming. That is, the traditional NAT does not allow any application control of the address translations that it performs. Additionally, since the address translation is performed on the message packets at such a low level within the kernel
84
, the NAT can add almost no value, other than providing the raw source address translation. The NAT cannot even provide any destination address translations, and does not fully support applications that either assume client and server addresses are both public and therefore equally accessible, or require that servers also initiate network sessions to clients. If added value is desired, such as centralized virus scanning, site blocking (parental-control filtering), white listing, caching (to speed up response-time), data-transformation (e.g. dithering of images to match screen size), etc., a proxy application must be used instead.
Traditional proxies, as illustrated in
FIG. 5
, are application programs existing in the user mode
86
that serve as the interface between the private
60
and the public
64
network (see FIG.
6
). Unlike NATs, the proxy
88
must be addressed directly by the client machines as seen in the destination address field
90
of message packet
92
, and therefore requires that the client applications C
1
, C
2
, etc. be setup to operate with a proxy
88
. Many applications cannot do this, or require specific configuration changes to allow the use of a proxy, and therefore a proxy configuration may not be appropriate, or even possible, for use with all applications.
When a proxy application
98
is used, all communications are sent to the proxy in the user mode
86
(see
FIG. 5
) as illustrated by lines
94
,
96
. The proxy
98
then determines whether and to whom to forward the communication on the public network. If the proxy determines that the message may be passed to a server on the public network, the proxy establishes a second session
100
, copies the data to the second session, changes the source and destination address, and sends out the message (see, also FIG.
7
). In operational terms as illustrated in
FIG. 7
, a client process C
1
establishes a first session
94
with the proxy
88
requesting access to a public server S
1
. If the proxy agrees, a second session
100
is established with the server S
1
on the public network
64
. Since all messages must pass from the kernel-mode network transport, e.g. TCP/IP
102
, to the user-mode proxy
98
, be copied to a second session, transferred back down to the kernel-mode driver
102
, and finally transmitted to the network for the network application's other session, a significant performance degradation occurs. However, proxy system promoters have begrudgingly accepted this performance degradation as the inevitable cost of the added value provided thereby.
Recognizing that the inability of various applications to utilize a proxy system precludes the adding of value to the network sessions using these applications, various software vendors have introduced transparent proxies. Transparent proxies operate like a traditional proxy in that they provide value to the network connection, and like a traditional NAT in that the network client need not specifically address them. The term transparent refers to the fact that the network client is unaware that its communication is being provided up to the proxy application. The client thinks that its communication is going directly to the network server, in much the same way as it does when a traditional NAT is used. However, the communication is actually redirected to the proxy application before being sent to the public network as illustrated FIG.
8
.
As may be seen from this
FIG. 8
, as a client C
1
on private network
91
attempts to contact a server S
1
on a public network
64
, the gateway machine
93
running the transparent proxy intercepts its messages. The transparent proxy operates by performing an address redirection through a traditional NAT
95
up to the proxy application
97
. Once the proxy
97
has processed the message, it is passed back down to be sent to the server S
1
. While this redirection is transparent to the client thereby allowing operation of the proxy with clients whose applications would not allow operation with a traditional proxy, this redirection is fixed within the NAT
95
. This requires that all communication be transferred up to the proxy at the application level or user-mode, and back down to the transport level or kernel-mode prior to being transmitted to the server. Therefore, the performance degradation of the traditional proxy discussed above still plagues the transparent proxy system.
SUMMARY
Dinh Dung C.
Leydig Voit & Mayer Ltd
Microsoft Corporation
LandOfFree
Application programming interface and generalized network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Application programming interface and generalized network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Application programming interface and generalized network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3324046