Browse Prior Art Database

System and method for more efficient sequenced record I/O processing using sockets over existing protocols

IP.com Disclosure Number: IPCOM000011972D
Original Publication Date: 2003-Mar-27
Included in the Prior Art Database: 2003-Mar-27
Document File: 3 page(s) / 55K

Publishing Venue

IBM

Abstract

Extend sockets API's to provide high throughput of sequenced application records.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

  System and method for more efficient sequenced record I/O processing using sockets over existing protocols

  Disclosed is a proposed extension to regular socket API's and to "asynchronous and overlapped I/O socket API's to provide high throughput of sequenced application records. The extensions allow an application to define it's record format for a recv() or an asynchronous "startReceive" operation. Then the application waits for complete sequenced records. Sockets system code processes incoming data and only returns or posts complete sequenced records to the application. Any incomplete records or out of sequence records remain queued at the socket layer.

  Scenario: A multithreaded source application or a single-threaded source application using an unreliable transport sends a sequence of records to a target application. The target application receives each record from sockets. The target application may receive records out of order and is forced to re-sort and temporarily store these records until the missing records are received.

  Currently, this scenario results in increased application complexity and storage requirements for queuing and sorting records. It also results in additional and unnecessary task switches on the target application since it will run (switch) when any record arrives but it may be unable to process an incomplete or out of order records and so will sleep (switch).

  As a result, some applications avoid the problem, and the target complexities, by single threading or serializing the source side. This can reduce overall throughput and increase task switches on the source. Or some applications may avoid using a fast, but unreliable transport, or may wait for an application return acknowledgement (ACK) for a record before sending the next record.

  The extensions build on the fact that sockets already queues data until the target application retrieves it. Now, if sockets understands the format and sequence of records it can queue and deliver the records to the application in correct order.

  The extensions result in the application no longer doing anything explicitly for record ordering. It also means fewer task switches and fewer socket calls (reduced path length) on the target because the application is only run (switch) when a working record is available. When done with the current record it can retrieve the next working record thus avoiding a call to sleep (and switch).

  They also allow source applications to use multiple threads to randomly send data records over one (datagram) socket without serialization. This increases throughput and reduces task switches on the source.

  It allows source applications to use fast, unreliable transports without excessive ACK processing. Since records are delivered in sequence on the target, windowed ACK's (ACK every N records) can be safely and efficiently used without excessive retransmitting from the source. This increases throughput and reduces network traffic. Opens the door for...