United States Patent r19i
`Bach et al.
`
`I lllll llllllll Ill lllll lllll lllll lllll lllll lllll lllll lllll llllll Ill lllll llll
`5,619,650
`Apr. 8, 1997
`
`US005619650A
`[11] Patent Number:
`[45] Date of Patent:
`
`[54] NETWORK PROCESSOR FOR
`TRANSFORMING A MESSAGE
`TRANSPORTED FROM AN 1/0 CHANNEL
`TO A NETWORK BY ADDING A MESSAGE
`IDENTIFIER AND THEN CONVERTING THE
`MESSAGE
`
`[75]
`
`Inventors: Maurice J. Bach, Haifa, Israel; Robert
`B. Hoppes, Hyde Park, N.Y.; Clifford
`B. Meltzer, Ossining, N.Y.; Kenneth J.
`Parchinski, Wappingers Falls, N.Y.;
`Gary J. Whelan, Rhinebeck, N.Y.
`
`[73] Assignee: International Business Machines
`Corporation, Armonk, N.Y.
`
`[21] Appl. No.: 531,579
`
`[22] Filed:
`
`Sep. 21, 1995
`
`Related U.S. Application Data
`
`[63] Continuation of Ser. No. 966,821, Dec. 31, 1992, aban(cid:173)
`doned.
`Int. Cl. 6
`...................................................... G06F 13/00
`[ 51]
`[52] U.S. Cl . ................................ 395/200.01; 395/200.14;
`395/285; 370/466; 370/469
`[58] Field of Search ..................................... 395/650, 500,
`395/200.01, 200.14, 285, 800; 370/85.1,
`85.13, 60
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,768,150
`4,855,905
`4,941,089
`5,124,909
`5,142,622
`5,251,205
`5,287,537
`5,307,346
`5,309,437
`5,327,558
`5,490,252
`
`8/1988 Chang et al. ........................... 364/300
`8/1989 Estrada et al. .......................... 364/200
`7 /1990 Fischer .................................... 3641200
`611992 Blakely ................................... 395/200
`8/1992 Owens .................................... 395/200
`10/1993 Callon et al .............................. 370/60
`2/1994 Newmark et al ....................... 395/800
`4/1994 Fieldhouse ............................. 370/85.1
`5/1994 Perlman et al ...................... 370/85.13
`711994 Burke et al ............................. 395/650
`2/1996 Macera et al ...................... 395/200.01
`
`Primary Examiner-Thomas C. Lee
`Assistant Examiner-Duo Chen
`Attorney, Agent, or Firm-Gerald R. Woods
`
`[57]
`
`ABSTRACT
`
`A system and method for distributing application-to-appli(cid:173)
`cation network communications protocol processing. Host
`computers implement distributed API processing across a
`high speed I/O channel increasing throughput. The applica(cid:173)
`tion API conforms to standard protocols but protocol pro(cid:173)
`cessing is distributed using a cross-channel distributed sock(cid:173)
`ets API at the session layer. This API allows multiplexing of
`data from one or more hosts to one or more front end routers
`managing network communications. Multiplexing increases
`network performance through parallel processing and
`advantageously employs host high speed I/O functions.
`Front end routers perform lower level protocol tasks neces(cid:173)
`sary to exchange data over the communications network.
`
`4,428,043
`
`1/1984 Catiller et al. .......................... 364/200
`
`7 Claims, 16 Drawing Sheets
`
`System 370/390
`
`J
`command Header '"'"''~:
`I DATAMSGr- J "
`'""~l DSM
`
`I Data
`+
`DSI Header
`
`Jt-1006
`
`write
`
`j
`
`=
`
`1008
`
`DSI Header
`command Header Channel Program
`I
`Data
`
`Channel r '1010
`Front End Router
`
`1012
`
`+
`DSI Header
`command Header
`Data
`
`DATAMSG
`
`OSI Header
`command Header
`
`Data
`
`I Data
`
`I
`
`Issue
`write()
`
`l
`I TCP/IP I
`
`Application
`
`'-
`
`1()02
`
`DSL
`
`CID
`
`1004
`
`DEFS-ALA0007042
`INTEL Ex.1020.001
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 1of16
`
`5,619,650
`
`Application 7
`
`108
`
`Computer A
`
`112
`Protocol
`Processor
`
`Presentation
`Session
`
`Transport
`
`Network
`
`Data Link
`
`6
`5
`4
`
`3
`
`2
`
`102 /"
`
`Physical
`
`1
`
`Media
`
`10t_
`
`LAN
`
`104 ~
`
`Physical
`
`1
`
`Media
`
`Data Link
`
`Network
`
`Transport
`
`Session
`Presentation
`
`2
`
`3
`
`4
`5
`6
`
`Protocol
`Processor
`114
`
`Computer B
`
`110
`
`Application 7
`
`-
`
`FIG. 1
`
`DEFS-ALA0007043
`INTEL Ex.1020.002
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 2of16
`
`5,619,650
`
`System 370/390
`
`Application
`
`Protocol
`Processor
`
`v-
`
`202
`
`-
`
`Presentation
`
`Session
`
`Transport
`
`Network
`
`Data Link
`
`Physical
`
`Bus & Tag
`
`Ch annel
`~
`20 4
`
`212-..,
`
`Control
`Unit
`
`214-..,
`
`Physical
`Data Link
`
`Data Link
`
`Physical
`208~ LAN
`
`PCA
`
`v-206
`
`LAN
`Board
`
`L AN
`B
`oard
`
`v- 210
`
`Physical
`
`Data Link
`
`Network
`
`Transport
`
`Session
`
`Presentation
`
`Protocol
`Processor
`
`Workstation
`
`FIG. 2 Prior Art
`
`Application
`
`DEFS-ALA0007044
`INTEL Ex.1020.003
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 3of16
`
`5,619,650
`
`System 370/390
`
`310
`
`Application
`
`~302
`
`Protocol
`Processor
`
`Application
`
`Protocol
`Processor
`
`Computer B
`
`FIG. 3
`
`DEFS-ALA0007045
`INTEL Ex.1020.004
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 4of16
`
`5,619,650
`
`r-----1~f 11 n I
`
`'C c w
`..... c
`0 ... u.
`
`FIG. 4
`
`O> c a:
`
`c
`())
`..x:
`0
`I-
`
`DEFS-ALA0007046
`INTEL Ex.1020.005
`
`

`

`!UCV
`Threads
`$18
`
`DSL sockets AP!
`5JQ
`
`'
`
`User
`exit
`Sooket ~ute. r. -·· __. ...... reads
`~ 1·
`l---~.l--A~---JC---r-tL-..L.~--4!
`I I
`Channel
`Channe!I
`Channel
`'i !
`Program
`Program
`Program
`i
`Thread
`Thread
`Thread
`
`3rd Party
`Drivers
`
`'
`.... I-,
`_
`
`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 5of16
`
`5,619,650
`
`System 3701390
`
`502
`
`Application
`504
`
`192.1.2.2
`
`TCP/JP
`
`'"---~~~_.__.... '===~-r-~__.._~--r--..r-----'---~~~j'--~--.-~~
`
`516
`
`192.1.3.2
`
`552
`
`l.
`560
`
`l
`562
`
`564
`
`OEM
`
`556
`
`FIG. 5
`
`DEFS-ALA000704 7
`INTEL Ex.1020.006
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 6of16
`
`5,619,650
`
`602
`
`•
`
`9.114.1.1
`
`PCNESCON
`
`CID Driver
`
`608
`
`612
`
`•• I
`
`604
`
`128.21.1
`
`192.2.1.1
`
`3172 Emulator
`
`Th ad Gr up Thread Group
`
`Up
`Down
`Stream Stream
`
`Accept
`
`DSM
`
`616
`
`TCP/IP Protocol Stack
`
`Lan Media Driver
`
`Lan Media Driver
`
`Lan Media Driver
`
`624
`
`626
`
`628
`
`610
`
`600
`
`FIG. 6
`
`DEFS-ALA0007048
`INTEL Ex.1020.007
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 7of16
`
`5,619,650
`
`DSL/DSM Socket Relationship
`
`Application
`
`SCB
`
`706
`
`704
`
`CCB
`
`708
`
`Application
`
`FIG. 7
`
`702
`
`DEFS-ALA0007049
`INTEL Ex.1020.008
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 8of16
`
`5,619,650
`
`DSL Control Blocks
`
`Application B
`socket (UDP)
`Bind(s, family, port, ip)
`
`Application A
`socket (TCP)
`bind(s, family, port, ip)
`listen()
`accept()
`accept()
`
`802 L-L...__.___.._.._,_..__ ___ __._,.._._ __ __._,_.. ______ _____.
`1999
`
`Socket
`Descriptor
`Table
`
`804
`
`SCB
`
`816
`
`SCB
`
`Primary
`Socket Control Block
`
`806
`
`Accept
`Queue
`
`808
`
`818
`
`810
`
`SCB
`
`SCB
`
`SCB
`
`SCB
`
`820 Multiple Link
`Socket Control
`Block
`
`TCP
`Socket Control
`Block
`
`Data
`
`812
`
`814
`
`822
`
`SLB
`
`SLB
`
`Server Link
`Block
`
`• • •
`
`FIG. 8
`
`DEFS-ALA0007050
`INTEL Ex.1020.009
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 9of16
`
`5,619,650
`
`DSM Control Blocks
`
`HLB Chain
`
`Primary CCB Chain
`
`HLB
`
`902
`
`HLB
`
`904
`
`•
`• •
`
`Secondary CCB Chain
`
`CCB
`
`CCB
`
`908
`
`CCB
`
`912
`
`CCB
`
`•
`•
`•
`
`•
`•
`•
`
`FIG. 9
`
`DEFS-ALA0007051
`INTEL Ex.1020.010
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 10 of 16
`
`5,619,650
`
`System 370/390
`
`Application
`
`l
`
`1002
`
`DSL
`
`CID
`
`DSM
`
`'--
`
`1004
`
`DEFS-ALA0007052
`INTEL Ex.1020.011
`
`~1006
`
`write J
`j
`
`-
`
`I Data
`+
`OSI Header
`command Header Build Frame
`=
`
`1008
`
`OSI Header
`command Header Channel Program
`I
`Data
`
`Channel ---.........1010
`Front End Router
`
`--
`
`Build API
`Issue
`write()
`
`j
`I TCP/IP I
`
`FIG. 10
`
`I DATAMSG~
`+
`OSI Header
`command Header
`
`1012
`
`Data
`
`DATAMSG
`
`OSI Header
`command Header
`
`Data
`
`I Data
`
`I
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 11 of 16
`
`5,619,650
`
`TCP/UDP socket(} call
`
`System 370/390
`
`Processing
`socket()
`
`I
`
`Socket Routing
`
`!
`Build OSI Headers
`i
`
`1106
`
`Channel Program
`
`Channel
`
`Application
`
`1104
`
`DSL
`
`1108
`
`1120
`
`1122
`
`1124
`
`1126
`
`postih
`
`j
`
`j
`
`j
`
`Recv Thread
`t
`Get DATA Buffer
`J,
`
`Call Listen Routine
`-.
`Enqueue DATAMSG
`t
`create down stream
`thread
`I
`
`11 28)
`
`first dispatch
`
`Send Thread
`
`CID
`
`1138
`
`Return socket
`message
`
`Build CCB
`
`Issue socket()
`
`DSM
`
`ll 1136
`Down
`ll 1134Stream
`
`Thread
`
`TCP/IP
`
`'l 1130
`
`_J
`1132
`
`Front End Router
`
`FIG. 11
`
`DEFS-ALA0007053
`INTEL Ex.1020.012
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 12of16
`
`5,619,650
`
`UDP/TCP bind()
`
`System 370/390
`
`Processing
`Bind()
`
`Socket Routing
`
`1204
`
`Build DSI Headers
`
`Return Code
`
`Channel Program
`
`Channel
`
`Application
`
`DSL
`1218
`
`Down
`Stream
`Thread
`
`1208
`
`TCP/IP
`
`1210
`
`1212
`
`Recv Thread
`
`Send Thread
`
`CID
`
`Validate Request
`
`Issue bind()
`
`No
`
`Bind Return
`Message
`
`DSM
`
`1216
`
`Create Upstream
`Thread
`
`1214
`
`Front End Router
`
`FIG. 12
`
`DEFS-ALA0007054
`INTEL Ex.1020.013
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 13 of 16
`
`5,619,650
`
`TCP connect() flow
`
`System 370/390
`
`Processing
`connect()
`
`Socket Routing
`
`I
`
`Application
`
`+
`Build OSI Headers I
`i
`
`I Return Code
`
`DSL
`1
`330
`
`Channel Program
`
`Channel
`
`Recv Thread
`
`Send Thread
`
`CID
`
`DSM
`
`1304
`
`postih
`
`Down
`Stream
`Thread
`
`TCP/IP
`
`Enqueue DATAMSG
`
`Validate Request
`
`lf 320
`
`'
`•
`•
`
`connect Return
`Message
`~132
`6
`
`'l.1322
`
`Issue connect()
`
`•
`
`Create Upstream
`J
`1324
`
`Front End Router
`
`FIG. 13
`
`DEFS-ALA0007055
`INTEL Ex.1020.014
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 14 of 16
`
`5,619,650
`
`TCP listen() flow
`
`System 370/390
`
`Processing
`Listen()
`
`Socket Routing
`
`I
`
`Application
`
`1404
`
`~
`Build OSI Headers I
`i
`
`I Return Code
`
`DSL
`
`Channel Program
`
`Channel
`
`Recv Thread
`
`•
`Enqueue DATAMSG
`1
`Validate Request
`1
`Issue listen()
`
`postih
`
`Down
`Stream
`Thread
`
`TCP/IP
`
`Send Thread
`
`CID
`
`'
`
`J410
`
`DSM
`
`Listen Return
`Message
`
`I
`
`l.1412
`
`l..142
`0
`
`•
`
`Create accept thread
`
`j
`1414
`
`Front End Router
`
`FIG. 14
`
`DEFS-ALA0007056
`INTEL Ex.1020.015
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 15 of 16
`
`5,619,650
`
`TCP accept() flow
`
`System 370/390
`
`Processing
`accept()
`
`Channel Program
`
`Channel
`
`1512
`
`I
`I
`151~ If accept on a then build scsj--
`return
`11....1520
`socket
`•
`+ I
`Bui\d accept message l \ Enqueue on SCB
`~
`
`A pp Ii cation
`
`OSL
`153
`0
`
`I
`
`Recv Thread
`
`•
`Enqueue DAT AMSG
`t
`Validate Request
`t
`store DSL socket
`t
`Create up & down
`Stream threads
`J
`
`postih
`
`Down
`Stream
`Thread
`
`)
`1540
`
`1542
`
`Send Thread I
`
`CID
`
`asynchronous
`accept message
`
`"- 1552
`
`·~
`
`DSM
`
`build CCB
`.
`
`Accept()
`
`I
`
`It-. 1550
`HTCP/IPI
`
`Front End Router
`
`FIG. 15
`
`DEFS-ALA0007057
`INTEL Ex.1020.016
`
`

`

`U.S. Patent
`
`Apr. 8, 1997
`
`Sheet 16 of 16
`
`5,619,650
`
`TCP/UDP Data Flow
`
`System 370/390
`
`Processing
`Sendto or () write()
`Recvfrom() or read( l_
`1650
`I
`I
`Application
`
`Socket Routing
`
`Fast
`Release
`
`+
`I Build DSI Headers
`160~
`+
`
`f
`+
`I Dequeue Recv
`i
`+
`Channel Program
`
`DSL
`1655
`
`Channel
`
`1610
`
`Recv Thread
`+
`Get DAT A Buffer
`
`Call Listen Routine
`
`1620\
`
`postih
`
`•
`•
`Enqueue DAT AMSG
`t
`Down
`issue
`Stream
`sendto() or write()
`Thread
`J
`1622
`
`CID
`1666
`
`i--1664
`v DSM
`
`Send Thread
`i
`Enqueue DATAMSG ,...__
`i
`issue
`recvfrom() or read()
`t
`Get DAT A Buffer
`T
`
`Up
`Stream TCP/IP
`Thread
`~'"" 1662
`
`Select() & IOCTL()
`
`l..
`1660
`
`Front End Router
`
`FIG. 16
`
`DEFS-ALA0007058
`INTEL Ex.1020.017
`
`

`

`5,619,650
`
`1
`NETWORK PROCESSOR FOR
`TRANSFORMING A MESSAGE
`TRANSPORTED FROM AN 1/0 CHANNEL
`TO A NETWORK BY ADDING A MESSAGE
`IDENTIFIER AND THEN CONVERTING THE
`MESSAGE
`
`The application is a continuation, of application Ser. No.
`07/966,821 filed Dec. 31, 1992 now abandoned.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention relates to systems for communicat(cid:173)
`ing between application programs over a telecommunica(cid:173)
`tions network. More particularly, the present invention
`relates to application to application communication using a
`defined protocol such as TCP/IP between systems which
`may include high performance input/output mechanisms.
`2. Background and Related Art
`Data processing systems are used for a large number of
`functions in business, research and education. The computer
`systems used for these functions are frequently geographi(cid:173)
`cally dispersed, but required to be interlinked for certain
`purposes. This has led to the creation of telecommunication
`networks linking computer systems and the creation of
`telecommunications protocols to assist in the orderly com(cid:173)
`munication between systems.
`Data processing application programs used with distrib(cid:173)
`uted computer systems often employ the client-server model 30
`for network applications. In this model, one or more com(cid:173)
`puter systems are designated as "servers" able to respond to
`requests from "clients" to perform various services. Server
`applications may provide functions such as printing, file
`storage, or processing resources. The server process is 35
`typically started in one computer system and is caused to
`wait and "listen" for a request by a client for service. Upon
`receipt of that request, the server wakes up and provides the
`requested service.
`Communications between client and server applications
`take place according to a defined network protocol. A
`protocol is a set of rules and conventions used by the
`applications participating in a conversation. The set of rules
`can become very complex and layered protocol models have
`been adopted to help simplify and manage network protocol
`definitions. The International Standards Organization (ISO)
`has developed the Open Systems Interconnection Model
`(OSI) for computer communications. The OSI model con(cid:173)
`sists of seven layers with well defined interfaces between the
`layers. Most computer network protocols are described in
`terms of the OSI model.
`FIG. 1 presents an example of a network illustrating the
`seven layer OSI model. Two computer systems are shown
`102 and 104. The systems are connected by a Local Area
`Network (LAN) 106. The OSI model is applicable not only
`to local area networks, typically connecting multiple com(cid:173)
`puters within a building, but also to wide area networks
`(WANs) connecting computers in different cities or coun(cid:173)
`tries and to internetworks (Internet) connecting several
`physically separate networks (either LANs or WANs).
`Application programs 108 and 110 communicate over
`LAN 106 via protocol processors 112 and 114. Protocol
`processors 112 and 114 are typically implemented as part of
`the operating system of the computer running the application
`program. The OSI protocol comprises the following seven
`layers: Application(7), Presentation(6), Session(S), Trans-
`
`2
`port(4), Network(3), DataLink(2), and Physical(l). The
`higher layers 4-7 operate on messages. The network layer 3
`typically operates on packets, the datalink layer 2 on frames,
`while the lowest level physical layer 1 operates on bits of
`5 data.
`In this illustration each computer has identical software
`layers and each layer logically communicates to the same
`layer at the other computer, except for the presentation layer.
`The physical layer is the hardware interface adapter. This
`10 portion physically connects to the other computer and con(cid:173)
`trols the signals on the communications media. The Data
`Link layer provides the hardware interface routines usually
`in terms of software. This layer generally handles the
`interrupts, framing and unfrarning. The Network layer pro(cid:173)
`vides internet routing or forwarding packets to other com-
`15 puters on the network. This is generally done with routing
`tables. The Transport layer provides the flow control, assem(cid:173)
`bly and disassembly of data from one computer to another.
`This layer has the most overhead in the protocol stack. The
`Transport layer sends control messages as well as data
`20 packets. The Session layer is the interface to the application
`program. In terms of TCP/IP often layers 4 and 5 are
`discussed conceptually as a single layer, known as the
`Transport layer. Layer 6 is the presentation layer. This layer
`provides common routines for applications but doesn't com-
`25 municate with its matching component on the destination
`computer. Layer 7 is the Applications layer. A file transfer
`program would be an example of an application.
`Several network protocols have been defined and are in
`use in computer networks. These include TCP/IP, Systems
`Network Architecture (SNA), and NetBios. The low level
`physical connection can operate on known technologies
`such as Ethernet, Token Ring, or long distance networks
`provided by the telephone companies.
`The TCP/IP protocol was defined by the U.S. government
`and is used to link many research and educational institu(cid:173)
`tions that perform work for the government. Its widespread
`use has resulted in many other companies adopting TCP/IP
`to be able to communicate with existing TCP/IP sites.
`40 Although developed before the OSI model, TCP/IP compo(cid:173)
`nents can be mapped to the seven layer model. The TCP/IP
`"process" layer encompasses OSI Presentation and Session
`layers. Two Transport layers are defined, Transmission Con(cid:173)
`trol Protocol (TCP) which provides a connection based
`45 protocol, and the User Datagram Protocol (UDP) which
`provides a connection-less protocol. Internet Protocol (IP)
`provides the Network layer for both TCP and UDP while the
`DataLink layer is met by the appropriate hardware interface.
`Returning to FIG. 1, application program 108 communi-
`50 cates via the network using an Application programming
`interface (API). The sockets protocol is one of the more
`prevalent application to application APis. The sockets API
`was developed for use on Digital Equipment Corporation
`(DEC) VAX computers (DEC and VAX are trademarks of
`55 Digital Equipment Corp.) by the University of California,
`Berkeley, as the BSD operating system, a derivative of the
`UNIX operating system. (UNIX is a trademark of Unix
`System Laboratories.) The sockets API defines the format
`and parameter content of the commands an application
`60 program uses to establish communications with another
`application. It defines the API for both client and server
`applications and for connection-less and connection-based
`links. The defined API functions cause the operating system
`to issue the necessary commands to establish a communi-
`65 cations link and to exchange data over that link.
`The sockets API has been implemented on a variety of
`computer systems from small microcomputers to large
`
`DEFS-ALA0007059
`INTEL Ex.1020.018
`
`

`

`5,619,650
`
`5
`
`4
`defined limit on the number of sockets open or communi(cid:173)
`cations networks served.
`It is yet a further object of the invention to provide a
`system that supports distributed network protocol process-
`ing.
`The system of the present invention communicates with a
`network having a specified protocol such as TCP/IP. Mul(cid:173)
`tiple application programs can be operating on the main
`processor (host) and they can be communicating with a
`number of other processors on different networks. The host
`system of the present invention has a high speed input/
`output (I/0) facility connected to a network front end router.
`The host system implements a standard API for interacting
`with application programs. The API messages are trans(cid:173)
`formed for network processing by the front end router. The
`API is logically distributed from the host processor to the
`front end router through the high speed I/O facility.
`The system of the present invention connects one or more
`20 host processors to each front end router and can connect one
`or more front end routers to each host. Front end routers can
`be connected in tum, to one or more telecommunication
`networks.
`The above described objects and other objects, features
`25 and advantages of the invention will be apparent from the
`following more particular description of a preferred embodi(cid:173)
`ment of the invention, as illustrated in the accompanying
`drawing wherein like reference numbers represent like parts
`of the invention.
`
`3
`mainframes. The sockets API has been implemented on IBM
`ES/9000 mainframes (IBM and ES/9000 are trademarks of
`the IBM Corp.) to provide network connectivity to programs
`running on those systems. This implementation has not been
`without problems, however, due to the differences in hard(cid:173)
`ware architectures between the IBM ES/9000 computer and
`the DEC VAX computer for which the sockets API was
`originally developed. IBM ES/9000 computers and other
`"mainframe" computers typically are capable of processing
`a large number of programs and provide very high speed 10
`input output (I/O) capabilities. High speed I/O is necessary
`to provide the great throughput characteristic of mainframe
`computers. I/O is typically implemented as I/O Channels on
`these systems, with the channels having the ability to
`transfer data into or out of the system without intervention 15
`from the main processor. Channels can transfer several
`hundred megabytes of data per second using data streaming
`techniques. Most LANs, WANs, and telecommunication
`networks, however, are more limited and transfer only a few
`kilobytes to at most five megabytes per second. This data
`transfer mismatch results in undesirable mainframe network
`performance when implementing protocols such as TCP/IP.
`FIG. 2 illustrates a prior art configuration for the connec(cid:173)
`tion of an IBM ES/9000 processor (having a System/370 or
`System/390 architecture) to a local area network. (System/
`370 and System/390 are trademarks of IBM Corp.) Proces(cid:173)
`sor 202 is connected through its channel 204 to a control unit
`206 that is connected to the LAN 208. The protocol pro(cid:173)
`cessor in processor 202 performs all of the network protocol
`functions such as formatting messages for transmission over 30
`the LAN. Control unit 206 accepts the transmission packets
`in physical adapter 212 which is adapted for channel attach(cid:173)
`ment and the receipt of high volumes of data, and places the
`packets on the LAN via physical adapter 214 that is adapted
`to attach to a network. The opposite flow takes place for 35
`packets received from the LAN.
`The processor 202 thus spends considerable processing
`time handling the routine network tasks in protocol proces(cid:173)
`sor section, and is generally unable to take advantage of the
`high speed I/O capabilities because of the limited receiving 40
`abilities of LAN 208. The processing time spent in these
`network tasks is therefore unavailable for more productive
`processing thereby reducing the overall effectiveness of the
`processor 202.
`A technical problem of improving the performance of
`large computer systems when engaging in network commu(cid:173)
`nications using standard protocols is therefore presented.
`
`45
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`FIG. 1 is a block diagram illustrating the layers of the
`open system interconnect model.
`FIG. 2 is a block diagram showing prior art host to
`network interconnection structure.
`FIG. 3 is a block diagram illustrating the preferred
`embodiment of the present invention.
`FIG. 4 is an overview of the interconnections permissible
`in a system according to the present invention.
`FIG. 5 is a block diagram illustrating selected host system
`components of the preferred embodiment of the present
`invention.
`FIG. 6 is a block diagram illustrating selected front end
`router components of the preferred embodiment of the
`present invention.
`FIG. 7 is an illustration of the logical structure of distrib(cid:173)
`uted sockets according to the present invention.
`FIG. 8 is a block diagram illustrating the control block
`structure of the host portion of the preferred embodiment of
`the present invention.
`FIG. 9 is a block diagram illustrating the control blocks
`employed in the front end router.
`FIG. 10 is an example of the process flow for network
`messages in a system embodying the present invention.
`FIGS. 11-16 are structured flowcharts illustrating the
`logic and datafiow for selected API commands using the
`preferred embodiment of the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`SUMMARY OF THE INVENTION
`
`50
`
`It is therefore an object of the present invention to offload
`routine network tasks from the main processor while main(cid:173)
`taining standard network protocols.
`It is a further object of the invention to provide multiple 55
`paths from the main processor to the network so that
`network traffic can be processed in parallel to increase
`throughput.
`It is yet another object of the invention to provide an
`ability to process network traffic from multiple main pro(cid:173)
`cessors in a single network connected processor.
`It is yet another object of the invention to allow the main
`processor to take advantage of its high speed I/O abilities
`without sacrificing network API compatibility.
`It is yet a further object of the invention to provide a
`network protocol processing system that contains no pre-
`
`60
`
`The preferred embodiment of the present invention will
`65 be described with reference to the figures. FIG. 3 presents an
`overview of the preferred embodiment. Application pro(cid:173)
`grams 310 are processed by host processor 302. Application
`
`DEFS-ALA0007060
`INTEL Ex.1020.019
`
`

`

`5,619,650
`
`5
`6
`to application network links are established using a standard
`invention is not limited as to the number of threads or front
`API such as sockets. The API accepts messages from the
`end routers. The preferred embodiment is fully multi(cid:173)
`Application 310 to the session/datalink 312. Session/
`threaded allowing connections limited only by processor
`datalink 312 is connected through high speed 1/0 channel
`resources. The process embodied in the channel program
`314 to front end processor 304 without further protocol 5
`threads will be described in greater detail below.
`conversion. Front end router 304 transforms the session
`Host computer system 502 is able to process a number of
`layer message received from session/datalink 312 to the
`application programs 504 and 506. Host computer systems
`physical form required by network 316 using defined trans(cid:173)
`are frequently partitioned into a number of address spaces
`port, network, and datalink protocols. Network 316 manages
`for running application programs. For example, in FlG. 5,
`communication with the remote application 320 running in 10
`the TCP/IP process 550, the applications and DSL API and
`processor 306.
`related programs 509, and the third party drivers 554 run in
`The preferred embodiment of the distributed sockets
`three separate address spaces. All applications running in
`interface (DSI) is implemented with computer software
`multithreaded address space 509 are able to access the
`running in the host processor 302, a high speed interface
`distributed sockets library (DSL) 508 for application to
`adapter between the host and front end router, and a software
`15 application communications. Inclusion of the DSL API and
`configured front end router. The front end router of the
`related channel program threads within a single address
`preferred embodiment is a microprocessor with a Micro
`space improves system performance by avoiding cross
`Channel bus, such as the IBM PS/2 computer. (Micro
`address space transaction processing overhead.
`Channel and PS/2 are trademarks of the IBM Corp.) Other
`A front end router according to the preferred embodiment
`configurations are possible, however, including incorpora(cid:173)
`20 of the present invention is shown in FlG. 6. Framing,
`tion of the front end router function within the high speed
`internet routing, and flow control, also known as the Data
`1/0 channel processing logic of the host processor.
`Link, Network and Transport layers of the communications
`A possible configuration of hosts and front end routers
`protocol stack, are performed by the front end router. Front
`according to the present invention is shown in FlG. 4. Hosts
`end router 600 is attached to host 602 through a channel
`25 cable 606. The connection can either be a parallel data bus
`402 and 404 are connected to front end routers 406, 408 and
`410. Each front end processor can be connected to one or
`connection or a serial connection, such as the IBM ESCON
`more network topologies 412, 414 and 416 or to other
`serial connection. (ES CON is a trademark of the IBM Corp.)
`networks via Internet 418. The possible configurations
`Each host connection has an associated Internet address
`include multiple hosts connected to each front end router,
`specified according to the well defined Internet class A, B,
`30 or C four octet address standard. For example, the link via
`multiple routers connected to a single host, multiple net(cid:173)
`works connected to each front end router, and multiple
`cable 606 to host 602 has Internet address "9.114.1.1".
`routers connected to each network or subnetwork. There is
`Channel cable 606 is attached to front end router 600
`therefore multiplexing at every level of the preferred
`through one of two channel adapter card 608 and 610.
`embodiment.
`Although only two channel adapter cards are shown, the
`FlG. 5 illustrates the host components of the preferred
`number actually employed is limited only by the physical
`embodiment of the present invention. The network commu(cid:173)
`constraints of the front end router enclosure. The channel
`nication process is implemented using a distributed sockets
`adapter cards 608 and 610 can be any known. adapter for
`API function 508. This function 508 implements a Distrib(cid:173)
`connecting a high speed channel output to a Micro Channel
`uted Sockets Library (DSL) allowing the distribution of API 40
`bus or similar computer. Examples are the IBM PCA adapter
`function from the host 502 to routers 560, 562 and 564 or the
`card and the IBM ESCON adapter card for connecting
`use of undistributed network functions such as host based
`respectively to parallel and serial channels. One or more
`TCP/IP 550 and control unit(s) 552 or other channel to
`internet addresses is associated with each channel adapter
`network drivers 554 and network adapter devices 556.
`card.
`Provision of a standard sockets library allows programs 45
`Channel Interface Driver (CID) 612 manages communi(cid:173)
`previously written to this interface to be used in the distrib(cid:173)
`cations with the host over the high speed channel. This
`uted environment of the present invention without modifi(cid:173)
`driver provides a session level interface for applications to
`cation. Examples of application programs that could be used
`communicate with the host system channel. The CID is
`include FTP file transfer program for accessing server files
`multithreaded allocating a send and a receive thread to each
`remotely, and NFS, network file system, allowing use of 50
`channel. CID driver 612, in turn, interfaces with one or more
`server files by remote file systems.
`Distributed Sockets Module (DSM) thread groups 614, 616
`The distributed sockets API 508 is a multithreaded pro-
`and 618 or with a 3172 emulator 620. Emulator 620 is
`cess operating on the host processor. Socket router 510
`provided to handle communications routed by the socket
`accepts DSL API commands and routes them to DSL chan-
`router through the prior art host based TCP/IP process. The
`nel program 512, 514 and 516 or to an interprocess com- 55 DSM thread groups, which will be discussed in greater detail
`munications thread 518 or user exit thread 520 depending on
`below, connect to the TCP/IP protocol stack 622 that pro-
`the specified configuration, the API command and the sup-
`vides TCP/IP data transformation and placement of the data
`plied parameters. The socket router supports the use of
`on one of the connected networks through LAN media
`multiple front end routers by managing the mapping of
`drivers 624, 626 and 628. Each subchannel is assigned a
`sockets to routers using the control block structures 60
`thread group and each socket has an upstream, downstream
`described below. The interprocessor threads 518 and user
`and, in the case of a TCP socket, accept thread within that
`exit threads 520 and their downstream devices form no part
`thread group. The TCP/IP protocol stack and LAN media
`of the present invention.
`drivers operate according to known principles and do not
`Channel program threads 512, 514 and 516 manage
`form a part of the present invention.
`communications with the front end routers 560, 562 and 65
`The logical socket connection formed by the preferred
`564. Although only three channel program threads and three
`embodiment of the invention is illustrated in FIG. 7. The
`routers are shown, the preferred embodiment of the present
`socket protocol allows application to application communi-
`
`35
`
`DEFS-ALA0007061
`INTEL Ex.1020.020
`
`

`

`5,619,650
`
`7
`