Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
1998-03-27
2002-01-08
Rinehart, Mark H. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C710S055000, C710S056000
Reexamination Certificate
active
06338090
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a method and apparatus for selectively using input/output (I/O) buffers as a retransmit vehicle in an information handling system and, more particularly, to a method and apparatus for selectively using such buffers in a client/server system in which a plurality of requesters are operating concurrently.
2. Description of the Related Art
In acknowledgment-based communication protocols, such as TCP/IP, there is a requirement to keep a copy of the user's data which is sent to a partner until an acknowledgment arrives indicating that the data has been received. If such an acknowledgment does not arrive in timely fashion, the user data must be retransmitted. Such retransmission recurs until either the desired acknowledgment arrives or a threshold number of retransmissions occurs. In TCP/IP the interval between retransmissions is not allowed to be smaller than one second, nor larger than 60 seconds and may increase as the number of retransmissions increases. Upon reaching the threshold number of retransmissions, a TCP/IP connection is dropped. Note that after the user makes a request to send the data, control is normally returned to the user. It is not permissible to suspend the user until the acknowledgment arrives, since the user may have further processing to perform and cannot be delayed. Once the user regains control, the user is free to modify the contents of the data area or to free the area which contained the data that was sent. Thus, it is not possible to merely remember where the user data resides and reaccess it for retransmission.
The standard approach to this problem is to make a copy of the user data prior to returning to the user. On many machines, such a copy may be quite expensive, depending on how much data is being copied, whether the source and/or target areas are in processor cache, the size of the processor cache and so forth. In general, large data copies are disruptive to good system performance and costly in machine cycles.
An alternative approach has been to change applications to obtain the I/O buffers beforehand and put the data directly there. When this can be done, there are no data copies. This alternative approach reduces portability and forces the application to manage system resources. This generally requires some sort of authorization, which is undesirable, from both an installation and an application developer point of view.
SUMMARY OF THE INVENTION
It is common for implementations of communications protocols to pre-allocate a set of I/O buffers so as to avoid this setup overhead in “real time” during an actual user request. The number of buffers allocated during initialization may well be less than the maximum number allowed in order to save physical storage. For ease of implementation, these I/O buffers are allocated in one or a few distinct sizes. For efficiency in using the channel subsystem, media and supporting software, requests from multiple users may occupy a single I/O buffer.
The solution involves using the I/O buffer as the retransmission vehicle and providing a control procedure to decide when a particular request merits this usage. If the request does not merit maintaining the I/O buffer in this way, then a copy of the user data is made into a system-maintained buffer (which can be pageable). To support multiple concurrent use of a single I/O buffer as a retransmission vehicle, a buffer-related use count is maintained. Furthermore the I/O buffer is not freed until acknowledgments arrive for all uses which depend on the I/O buffer copy of the data for retransmission.
From a system resource point of view it is undesirable to keep an entire I/O buffer tied up for relatively small amounts of data. Furthermore the cost of copying small amounts of data is minor, probably no worse than the overhead of managing and tracking the I/O buffer usage itself Toward this end, an implementation-specific threshold for the amount of data required to keep the I/O buffer is chosen based on the I/O buffer size and the relative cost of copying data.
It is also undesirable to tie up the I/O buffer for long periods of time, since the number of I/O buffers is typically constrained by some external limit. Even without such an external limit, the I/O buffers represent a special resource since they are not available to the system for other usage, nor can the physical storage be reassigned for other purposes. In the absence of some external limit, there will be some internal limit to prevent consuming all available storage for I/O buffers.
If the system runs out of I/O buffers and a new request to send data arrives, then the request must either be suspended or refused. The former approach violates the principle that the user not be delayed (and is more complex), so it cannot be used. The latter approach implies that some sort of redrive mechanism must exist and the user data must be copied to a system managed buffer. As the redrive mechanism represents a delay and additional system overhead, it is undesirable to run out of buffers. This is true even when this procedure is not in place or when no requests are using I/O buffers as a retransmission vehicle, so that an adequate number of I/O buffers must be allowed. This procedure maximizes the use of I/O buffers within the limits established to decrease the effective instruction pathlength.
Thus it is desirable to have some insight into how long it will take before the expected acknowledgment should arrive so that the I/O buffer is not tied down for a given request. In protocols such as TCP/IP there is a measured average round-trip time (RTT) which can be used as an indication of the expected usage time for the I/O buffer for a given request, as this represents the time to receive the acknowledgment once the data is sent.
When retransmission occurs it is assumed to be due to problems in the network or possibly on the remote host (it could also be due to problems locally, but this is not material). While retransmission could be done from the I/O buffer if the data is maintained there, it is uncertain how much longer it will take to get an acknowledgment which is already tardy. Therefore, in the solution described here, retransmission causes the system to copy the data to be retransmitted from the I/O buffer (if present) to a system managed buffer. A simple timer mechanism can be used with this same purpose if the retransmission mechanism is too lax
REFERENCES:
patent: 3772653 (1973-11-01), Brown
patent: 4672570 (1987-06-01), Benken
patent: 4701911 (1987-10-01), Ulug
patent: 4807224 (1989-02-01), Naron et al.
patent: 5113394 (1992-05-01), Kotzin
patent: 5189672 (1993-02-01), LeBihan
patent: 5255268 (1993-10-01), Cato et al.
patent: 5359715 (1994-10-01), Heil et al.
patent: 5394526 (1995-02-01), Crouse et al.
patent: 5410536 (1995-04-01), Shah et al.
patent: 5432909 (1995-07-01), Cok
patent: 5459725 (1995-10-01), Bodener et al.
patent: 5546546 (1996-08-01), Bell et al.
patent: 5548735 (1996-08-01), Chen et al.
patent: 5561824 (1996-10-01), Carreiro et al.
patent: 5563874 (1996-10-01), Kant
patent: 5604866 (1997-02-01), Kolb et al.
patent: 5659687 (1997-08-01), Kim et al.
patent: 5659794 (1997-08-01), Caldarale et al.
patent: 5664116 (1997-09-01), Gayton et al.
patent: 5684797 (1997-11-01), Aznar et al.
patent: 5701427 (1997-12-01), Lathrop
patent: 5774479 (1998-06-01), Lee et al.
patent: 5894583 (1999-04-01), Johnson et al.
patent: 5918002 (1999-06-01), Klemets et al.
patent: 5930261 (1999-07-01), Shemla et al.
patent: 5931915 (1999-08-01), Benner et al.
patent: 6052385 (2000-04-01), Kanerva et al.
patent: 6092141 (2000-07-01), Lange
patent: 6240473 (2001-05-01), Houg
patent: 06069957 (1994-03-01), None
patent: 07271722 (1995-10-01), None
Danzig, Flow Control for Limited Buffer Multicast, IEEE 1994.*
IBM Technical Discl. Bulletin, vol. 37, No. 02B- 2/94 “Transport Application Programming Interface Extension for Multimedia” pp. 11-13.
Emmes David B.
Schmidt Donald W.
Kinnaman, Jr. William A.
Rinehart Mark H.
Vu Thong
LandOfFree
Method and apparatus for selectively using input/output... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for selectively using input/output..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for selectively using input/output... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2868061