CA2104076C - Session oriented connectionless data transfer for a computer network - Google Patents
Session oriented connectionless data transfer for a computer networkInfo
- Publication number
- CA2104076C CA2104076C CA002104076A CA2104076A CA2104076C CA 2104076 C CA2104076 C CA 2104076C CA 002104076 A CA002104076 A CA 002104076A CA 2104076 A CA2104076 A CA 2104076A CA 2104076 C CA2104076 C CA 2104076C
- Authority
- CA
- Canada
- Prior art keywords
- protocol
- session
- messages
- sideband
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
Abstract
A session-oriented local area network (LAN) application and an ISO 8802-2 protocol driver code will cooperate in a new form of connectionless, session-oriented communication called Sideband. At each session start-up time, the LAN
Application will communicate with the enhanced ISO 8802-2 based protocol driver on the local system and the LAN
Application and the 8802-2 based protocol driver on the remote system to determine if they all support the Sideband.
If Sideband is fully supported by both systems, Sideband will be activated for the session. To communicate on a session which has Sideband active, the LAN Application requests that data is to be sent using the Sideband. A
check is performed to see if the data meets Sideband criteria. As Sideband is a connectionless medium, the additional code path needed to set Up and track timers and to handle the resend attempts are saved in the protocol. If the LAN Application code is session-oriented, it will keep track of a timer which will cause the data to be resent along a non-Sideband path if a response is not received within a designated amount of time. Header information is stored and reused to increase the throughput and decrease the response time for the transmission of small network packets. In case the network at some points becomes unreliable, procedures are used to track the reliability of the network and to enable and disable Sideband in accordance with the reliability of the network.
Application will communicate with the enhanced ISO 8802-2 based protocol driver on the local system and the LAN
Application and the 8802-2 based protocol driver on the remote system to determine if they all support the Sideband.
If Sideband is fully supported by both systems, Sideband will be activated for the session. To communicate on a session which has Sideband active, the LAN Application requests that data is to be sent using the Sideband. A
check is performed to see if the data meets Sideband criteria. As Sideband is a connectionless medium, the additional code path needed to set Up and track timers and to handle the resend attempts are saved in the protocol. If the LAN Application code is session-oriented, it will keep track of a timer which will cause the data to be resent along a non-Sideband path if a response is not received within a designated amount of time. Header information is stored and reused to increase the throughput and decrease the response time for the transmission of small network packets. In case the network at some points becomes unreliable, procedures are used to track the reliability of the network and to enable and disable Sideband in accordance with the reliability of the network.
Description
i AT9-92-092 2 1 b 4 0 7 6 - Description SESSION ORIENTED ~ lONLESS DATA TRANSFER
FOR A ~ul~ NETWORK
Background of the Invention This invention relates generally to data processing systems - in an interconnected environment. More particularly, it relates to an improved method for transmitting small packets of data in a data processing system in an interconnected environment.
It is becoming increasingly prevalent to couple a plurality of data processing systems in an interconnected computing environment such as a Local Area Network (LAN) or Wide Area Network (WAN). The net works are becoming increasingly complicated, with several different LAN networks of different protocols coupled together with the data processing systems from multiple vendors in the network. To assure that different network technologies can communicate with each other, most vendors provide capability to interface according to the IEEE and International Standard Organization's standards for Local Area Networks. ISO 8802-2 (IEEE Standard 802.2-1989) Logical 1ink Control Protocol describes the data link layer in a Local Area Network. ISO
8802-3 (IEEE Standard 802.3-1988) describes a bus utilizing CSMA/CD as the access method. ISO 8802-4 (IEEE Standard 802.4-1985) describes a bus utilizing token passing as the access method. ISO 8802-5 (IEEE Standard 802.5-1989) describes a ring utilizing token passing as the access method. ISO 8802-7 describes the ring utilizing a slotted ring as the access method. This family of standards deals with the physical and data link layers as defined by the ISO
open systems interconnection reference model.
The data link layer described in ISO 8802-2 consists of a top or logical link control (LLC) sublayer and a bottom layer or medium access control (MAC) sublayer which is defined to complete the functionality of the data link layer _ _ . ...... _, _ _ . _ _ _ . __ __ ~ . . _ _ _ __ , _ , .
has two LLC protocols for communication between two systems in the network to satisfy a broad range of potential applications. The ISO 8802-2 LLC type 1 protocol is a connectionless protocol with minimum protocol complexity which has no guarantee of delivery to the receivinq system and is described in Section 6 of the ISO standard. This mode is useful when the higher layers, e.g., applications, provide any essential recovery and sequences so they do not need replicating in the data link layer. This type of operation also is useful in applications where it is not essential to guarantee the delivery of every data packet.
The ISO 8802-2 LLC type 2 protocol is a connection-based protocol for guaranteed delivery. This mode includes support of sequence delivery of data link layer units and a comprehensive set of data link layer recovery techniques.
This second type of operation is described in section 7 of the ISO standard. Because many network servers and message transfer interfaces, such as IBM's LAN Server. and NetBIOS., call for session-oriented data transfer between two systems on a network. To track transactions for each client, they are generally forced to use a session-level protocol and the 802.2 type 2 protocol on all data transfers. While this data transfer method can be efficient for large messages, for small messages the performance is relatively poor.
r Brief Description of the Invention It is therefore an object of the invention to increase throughput and decrease response time for transmission of small network packets.
This and other objects of the invention are accomplished by using the knowledge that a network is normally reliable.
Extensions to an LAN Application and an enhanced Protocol driver which include the ISO 8802-2 protocol and the NetBIOS
protocol driver will cooperate in a new form of connectionless, session-oriented communication called the Sideband. In Sideband, header information is stored and reused to increase the throughput and decrease the response time for the transmission of small network packets.
~, 2~04076 At each session start-up time, the LAN Application will communicate with the enhanced IS0 8802-2 protocol driver to determine if they both support the Sideband. Also, the requestor system on which the LAN Application and the enhanced protocol driver are resident will determine if Sideband is supported on the receiving system to which Sideband Communication will be sent. If Sideband is fully supported by both systems, Sideband will be activated for the session.
When it comes time to communicate on a session which has Sideband active, the LAN Application may request that the information is to be sent using the Sideband path. If so, enhanced protocol driver will check to see if the data meets Sideband criteria, e.g., will fit into a single packet and will attempt to send the packet Sideband if it meets the criteria. As Sideband is a connectionless medium, the additional code path needed to set up and track timers and to handle the resend attempts are saved in the protocol. If session-oriented responses are important to the LAN
Application code, it will keep track of a timer which will cause the data to be resent alonct the non-Sideband path if a response is not received within ~ designated amount of time.
For further code path savings, the enhanced protocol driver code will store the header and trailer information for a session. Since the header and trailer information remains constant for all single packets sent across a session in Sideband, the time needed to follow the normal code path needed to fill in this data is eliminated.
Sideband is dependent on a reliable network. In case the network at some points becomes unreliable, procedures are used to track the reliability of the network and to enable and disable Sideband in accordance with the reliability of the network.
Brief De~cription Of The Drawing~
FIG. 1 depicts a typical workstation whlch would be coupled 210407~
to a network environment in accordance with the present invention.
FIG. 2 depicts a plurality of workstations in a network environment according to the present invention.
FIG. 3 depicts the code modules in the memory of a ~ workstation using LAN Server and NetBIOS according to ISO 8802-2 and the present invention.
FIGs. 4A-C depict communication using NetBIOS session oriented, datagram and Sideband communication modes according to ISO 8802-2.
FIGs. 5A-C depict the frame header f.ields for Session, Datagram and Sideband comm~lnication respectively.
FIG. 6 is a flow diagram for the process for establishing the Sideband session.
FIG. 7 is a flow di.agram for sending a message by Sideband.
FIG. 8 depicts Sideband communicatioll between two workstations on the network.
.. ......
FIG. 9 is a flow diagram to determine whether the network is sufficiently reliab]e to use Si.deband FIGs. lOA-C depict disabling and enabling Sideband across a network.
FIG. 11 shows the fields in a Network Control Block (NCB).
Detailed Description of The Invention A representative hardware environment is depicted in FIG. 1, which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units interconnected 210407fi via a system bus 12. The workstation shown in FIG.
includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter 34 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to display device 38.
The preferred embodiment of the s~lbject invention is an IBM~
Personal System/2~ with the IBM OS/2 Operating System~
installed. Detailed descriptions of the hardware and software environment are provided in PS/2 Hardware Interface Technical Reference, SlOG-6457, IBM Corporation (1991), and OS/2 Presentation Manager Programming, SC28-2700, IBM
Corporation (1992). While the invention will be described in terms of this hardware and software, one skilled in the art will recognize that other operating systems and hardware can be supported without undlle experimentation. Also resident on the computer system is the OS/2 LAN System Software support including the software maki ng up the subject invention. The system software llsed in the previous release is described in the following pnhlications available from IBM: IBM Operating System/2 I,oca] Area Network Server Version 2.0 Information an~3 Planllinc3 Guide (G236-0162); IBM
Local Area Network Server Programs (Specification Sheet) (G360-2753); and IBM Local Area Network Technical Reference (SC30-3383).
Interconnected computing environments are becoming much more prevalent. Network environments are becoming more varied, consisting of different LAN technologies, multiple vendors and multiple adapters. There is also a higher performance requirement and a greater need for network management. FIG.
2 is an illustration of a typical computer network environment comprising a plurality of interconnected workstations similar to that shown in FIG 1.
FIG. 2 illustrates a local area network 40 which is preferably a IBM Token Ring, however, it could also be an Ethernet or PC net or other LAN type system. OS/2 requester 42 communicates via LAN 40 to LAN Server server 44 for file sharing, application server database server, print server, communications server and other services. The OS/2 Requester 42 as, might be suspected, runs on the OS/2 2.0 operating system. The DOS Requester 46 communicates by means of Bridge 48 to LAN 40 to request similar .services from the LAN Server server 44. The DOS Requester 46 runs on the DOS Operating System 5Ø The Bridge 48 is used to couple the DOS
Requester 46 and Network Server 50 via Ethernet 51 to the LAN 40. The Netware Server 50 runs on the Novell Netware~
local area network software and provides an example of the level of integration of vendors which is possible in today's local area networks. The OS/2 SNA gateway 52 provides service to the LAN 40 via bus 54 to the other networks which operate on the SNA Protocol. Finally, powerful RISC based workstations such as the RISC System/6000~ 56 can also be coupled to the local area network 40.
FIG. 3 illustrates the architectural block diaqram of the software applications at least a subset of which would be resident in the RAM access memory of a workstation on the LAN. Generally, this software configuration is known as the LAN adapter and Protocol Support (LAPS) consists of the network communication software necessary to support LAN
connectivity. LAPS is a combination of Network Driver Interface Specification (NDIS) compliant protocol drivers, NDIS compliant network adapter drivers, Application Program Interface (API) support software, and configuration and installation software for the drivers. The IBM Network Basic Input/Output System NetBIOS) has been extended to interface to NDIS and to the 802.2 specification.
NetBIOS function is provided by the NetBIOS box 60 and the IBM OS/2 NetBIOS Protocol driver or NetBEUI 62. The NetBIOS
block 60 provides the mapping functions, mapping OS/2 application calls to the NetBEUI Protocol 62. The NetBIOS
Protocol driver 62 takes the NetBEUI mapping or LAN Server 210~076 - or LAN Requester request and processes them according to the NetBIOS Protocol. This protocol is defined in Local Area Network Technical Reference, (SC30-3383-3).
i LAN Server 64 performs file sharing, application server, database server and other similar functions for workstations coupled to the local area network. LAN Requester 66 provides the user access to the functions provided by a LAN Server 64 located at a different workstation in a local area network.
RDS DOS support 70, supports database functions from the database server product part of the Extended Services for OS/2 2Ø This is a NetBIOS application and would pass its messages through NetBIOS 60 before going to the NetBIOS
Protocol driver 62. NetBIOS applications 72 also pass messages directly to NetBIOS 60. There is an advantage in using NetBIOS, rather than the IEEE 802.2 Protocol driver 74 in that the LAN application can be much simpler and it not know all the protocol functions. The IEEE 802.2 Protocol driver 74 performs similar functions as the NetBIOS Protocol driver 62, but according to the IEEE 802.2 Protocol. The NetBIOS Protocol driver 62 has two protocol layers, the NetBIOS protocol layer and the 802.2 Protocol layer. The network protocol drivers 62, 7~ provides the communication between an application and a network adapter driver 92.
Remote Installation Program Load (RIPL) 68 allows a remote initialization of a workstation from the server. SNA-LAN DLC
76 provides an SNA interface to the 802.2 Protocol. SQL L00 interface 78 provides a fastpath for databases to the 802.2 Protocol driver. Among the API's which utilize the SNA-LAN
DLC 76 interface are the SNA gateway 80, the PPC-LU 6.2 API
82, the LU2 API 84 and the LUA API 86. Databases such as remote data services 88, can use the SQL LOO interface 78 to the 802.2 Protocol Driver 74. NDIS 90 is a standardized Medium Access Control (MAC) Interface for network adapter drivers and protocol drivers. NDIS has become an industry standard for network adapters and LAN software to communication with each other. NDIS separates protocol handling from hardware manipulation by defining functions that protocol drivers 62 and 74 and network adapter drivers 92 must provide to each other. NDIS defines specifications - - - : - -210~07~
for network protocol drivers 62, 74, Adapter drivers 92, and the interfaces between the two and a binding process to link the protocol and adapter drivers. Network Adapter Drivers 92 provide the software interface to network adapters 94, such as the Token Ring Ethernet or PC Net Adapters.
Session, Datagram and Sideband NetBIOS data transmission examples are shown in FIGS. 4A, 4B and 4C respectively. Note that Session data transfer receives an acknowledgement response (DATA_ACK) from the receiving node to the initial data packet (DATA_ONLY_LAST), whereas in the both Datagram and Sideband transfer, no acknowledgement takes place, either at the NetBIOS protocol layer or at the 802.2 protocol layer. This is due to the fact that Session transmission uses ISO 8802-2 LLC type 2 transmission services which requires an LLC response, and NetBIOS Session protocol which requires a NetBIOS response. Datagram and Sideband transfer, on the other hand, use ISO 8802-2 LLC
type 1 transmission which does not require an LLC response back from the receiving node. Also, the Datagram and Sideband NetBIOS protoco]s clo not require a NetBIOS
response.
At the NetBIOS protocol level, the session is an association of facilities necessary for establishing, maintaining, performing data transfers and releasing logical connections for communications between stations. The prior art NetBIOS
Session protocol performed these functions exclusively on the logical link connections of ISO 8802-2 Type 2 (connection-oriented) protocol. The Sideband NetBIOS
protocol allows the data transfer function of the session to be performed on ISO 8802-2 Type 1 (connectionless) protocol.
LLC connectionless and connection oriented services are defined in detail in section 2.1 of the ISO 8802-2 standard.
The present invention is preferably embodied in changes to the NetBIOS Protocol Driver 62 and a NetLIOS application such as LAN Server 64 or LAN Requester 66 which make them aware of the Sideband and able to transmit data by the Sideband.
- - -2~04076 FIGs. 5A, 5B and 5C illustrate session-frame, datagram-frame and Sideband frame, header fields respectively. Both session-level and datagram transmission are known in previous versions of netBIOS.
NetBIOS session-level data transfer ~lses NetBIOS send and receive commands for guaranteed delivery of messages. It uses NetBIOS I-frame headers on 802.2 type 2 I-frames for guaranteed delivery. The SESSION Frame Header Fields as shown in FIG. 5A are as follows:
. .
MAC header - Varies with LAN type (IEEE 802.5, 802.3 etc.
LLC header - [ FO FO XX YY ] A normal IEEE 802.2 I
frame, type 2, LLC header.
.
(the remaining fields are in the format of a normal NetBIOS
I-frame header.) NetBIOS Header Length - [ OE 00 ] Specifies a 14-byte NetBIOS header.
NetBIOS Signature - [ FF EF ] Identifies the frame as a NetBIOS frame.
Command Code - 115/16 1 Data -First-Middle or Data-Only-Last Command.
DATAl - No-Ack and Receive - Continue Flags.
DATA2 - Resynk Indicator Xmit Correlator - Piggyback Ack Correlator or O(not used) Rcv Correlator - 2-Byte Correlator from Sender, Used For Acknowledge Destination LSN - [session-specific ]
l-byte destination session number.
Source LSN - [ session-specific ]
l-byte source session number NetBIOS datagram traffic uses NetBIOS datagraphy and broadcast datagram commands to send non-guaranteed messages, ~- - - - --it uses NetBIOS datagram UI headers on top of 802.2 type 1 UI frames. The DATAGRAM Frame Header Fields as shown in FIG.
5B are as follows:
MAC - Varies with LAN type (IEEE 802.5, 802.3 etc.) LLC header - [ FO FO 03 ] A normal IEEE 802.2 UI
frame LLC header, type I.
NetBIOS Header Length - [ 2C 00 ] Specifies a 44-byte NetBIOS
header.
NetBIOS
_ Signature - [ FF EF ~ Identifies the frame as a ~_- ' NetBIOS frame.
Command Code - [ 8, 9 ] Data-Only-La~t command.
Indicates the frame is the last piece of the SEND.
DATAl - [ 00 ] Set to O but not used by the receiver.
DATA2 - [ 00 00 ] Set to O but not used by the receiver.
Xmit Correlator - [ 00 00 ] Set to O but not used by the receiver.
Rcv Correlator - [ 00 00 l Set to O but not used by the receiver.
Destination Name - [ 16-Byte Name of Receiver session number.]
Source Name - l 16-Byte Name of Sender session number]
Sideband uses Sideband sends and normal session receive commands to send non-guaranteed, session-oriented data.
Sideband uses a NetBIOS I-frame header on top of an 802.2 UI
frame on 802.2 type 1 frame with a special field to indicate that it is a Sideband message. The SIDEBAND Frame Header Fields as shown in FIG. 5C as follows:
MAC header - Varies with LAN type (IEEE
AT9-92-092 ll - 802.5, 802.3 etc.~
LLC header - [ FO FO 03 ] A normal IEEE 802.2 UI frame, type l, LLC header.]
SB Signature - I OF] A one-byte signature value which can be checked by the receiving NetBIOS protocol to identify the received frame as a Sideband frame.
(The remaining fields are in the format of a normal NetBIOS
I-frame header.) NetBIOS Header Length - I 00 00 ] Specifies a 14-byte NetBIOS header.
NetBIOS Signature - [ FF EF 1 Identifies the frame as a NetBIOS frame.
' Command Code - [ 16 ] Data-Only-Last command.
Indicates the frame is the last piece of the SEND.
DATAl - 1 00 00 ] Set to O but not used by the receiver.
DATA2 - 1 00 ~~ 1 Set to O but not used by the receiver.
Xmit correlator - 1 00 00 I Set to O but not used by the receiver.
Rcv Correlator - I 00 00 J Set to O but not used by the receiver.
Destination LSN - ¦ session-specific ]
l-byte destination session number Source LSN - Isession-secific]
l-byte source session number.
FIG. 6 is a flow diagram for the process for establishing the Sideband session. The process begins step lOO where NetBIOS is called by a NetBIOS application to establish a session using Sideband. The command to establish a session can either be a Sideband li,sten or a Sideband call. Next, a test is performed to determine whether a Sideband is enabled s~
210407~
locally in step 102. If not, a normal NetBIOS session is established and an error code is returned to the calling application in step 104. To establish a normal NetBIOS
session, the procedures outlined in Chapter 5 of the LAN
Technical Reference (SC30-3383) are followed. If Sideband is enabled locally, the NetBIOS session is initiated. Sideband support is negotiated in Step 106. Establishing a Sideband session is similar to establishing a normal NetBIOS Session in step 104, except that an additional negotiation on a single bit is required for Sideband support. Next, a test is performed to determined whether Sideband is supported remotely in Step 108. If not, the normal NetBIOS session is established in Step 104. If it is supported remotely, the Sideband session control block is built with a connectionless header in steps llO and 112. First, a Medium Access Control (MAC) layer and LCC layer UI Type 1 header and the new Sideband header for that session are built in step 110. Next in step 112, the NDIS frame descriptor is built with immediate data pointers set to the pre-built header built in the previous step Sideband availability c~n be determilled on both ends of a session which is being established. Three methods were discussed to handle this, two of the methods being implemented by the NetBIOS protocol driver, and the third would have to be done by LAN Server. The first method is for the NetBIOS protocol driver code to determine availability at CALL/LISTEN time of the session setup using a new bit, and then to pass the new bit to LAN Server using a return code. Most of the new coding would be in Net Bios, LAN
Server would merely add the code needed to handle the new return code. The second method would be to use a SESSION_ALIVE call, and if a response is received, then Sideband is available. The third method is for LAN Server to use a new SMB protocol to handle the Sideband availability determinations.
Once the Sideband session is established and the Sideband message header is built, NetBIOS is ready to issue a Sideband send command. The process flow for a Sideband Send 210~076 i8 illustrated in the flow diagram in FIG. 7. NetBIOS is called by a NetBIOS application to issue a Sideband send command in step 120. Next, a test is performed to determine whether Sideband is active in this session in Step 122. If not, the Sideband send request is rerouted to a non-Sideband send path in step 124. A save return code is saved so that when the response to the initial message is made, the save return code is returned to indicate that the send request was sent on a non-Sideband path. If Sideband is active on the session, a second test is performed to determine whether the message will fit in one frame in Step 126. If not, the message is rerouted to a non-Sideband send as described in step 124. If the message does fit in one frame, the pre-built Sideband headers as described in Steps 110 and 112 in FIG. 6, are used to issue the frames to the lower level, for example, the NDIS level. Finally, a completion code is returned to LAN Application which requested the Sideband Send in Step 130.
In the preferred embodiment, the network only uses Sideband if the data packet is small, l.e., it-. fits in one Medium Access Control (MAC) frame. The MAC frames are used to communicate off the LAN and are described in the ISO 8802-3, 8802-4, 8802-5, 8802-7 standards. Thls determination could be made by either an app].ication such as the LAN Server code or by the NetBIOS protoco] driver code as modified for the invention. For the L~N Serve1 code to determine the size of the data packet, an inter~ace is established by which the NetBIOS protocol driver wou]d return the maximum space available for data in a network packet. LAN Server code would then subtract from thi.s amount however much space is needed for the SMB and other header information, and then determine if the data to be sent woul.d fit in the remaining storage space. Alternatively and preferably, the enhanced NetBIOS protocol driver code determines the size of the data packet. This eliminates the need for the interface to the LAN Server. It also reduces the decision path to be limited to one place (in the NetBIOS protocol driver) as opposed to at least two places (in the Ring 0 Server and in the Redirector) which would be necessary in the LAN Server code.
~ According to the flow diagram, if enhanced NetBIOS
determines the data will not fit into a single packet, and it had been asked to send the data on the Sideband path, then it will return an error saying the data did not fit in a single buffer. It will then transfer the data along the non-SB path.
If LAN Server code reguests that a piece of data be sent along the Sideband path by the NetBIOS protocol driver, and it is then not sent Sideband, then the NetBIOS protocol driver will notify the sending system and then send the data packet non-Sideband. Three return codes are used to indicate why the data was not sent Sideband. The first will handle the case that Sideband was active, but the data to be sent did not fit into a single MAC packet (SB_ERR_DATA_TOO_LARGE), and the second is for the case that Sideband has been disabled (SB_ERR_SB_DISABLED). The third return code indicates that the MAC layer cannot accept the frame immediately (SB_ERR_MAC_FULL).
A NetBIOS application which is aware of Sideband such as LAN
Server must be able choose when to send a particular data packet using Sideband and will have a means of indicating to the NetBIOS protocol driver which protocol it would like to have used. There are at least three methods for complying with thi 8 requirement:
First and preferably, a new set of different command codes indicate to NetBIOS protocol driver that Sideband should be used are defined. New command codes require the use of five new Network Control Blocks (NCBs), which both LAN Server and NetBIOS protocol driver handle NCB are discussed Chapter 4 of the LAN Technical Reference. To implement the new command codes without adding a test in each code path, a mapping table was created. Before each send of an NCB, the SB_ENABLED flag is checked, and if it is set, the code executes a few instructions to do the mapping. Checking the flag requires a little more memory (2-4 bytes per non-SB
t command), but would require minimal extra code path.
~ AT9-92-092 15 210~6 Second, a unique entry point and interface could be defined from LAN Server to NetBIOS protocol driver. This option is less preferred if the LAN Server and Net BIOS code would therefore require significant code changes in both the LAN
Server and NetBIOS protocol driver code.
Third, a register value as a flag for LAN Server to indicate to NetBIOS protocol driver that Sideband is to be used for this request could be defined. This would seem to be the easiest method to implement. The only changes to the LAN
Server code path would be to check if Sideband was enabled and to set this register appropriately at the time the NCB
command is submitted to NetBIOS protocol driver. The same entry points and command codes will be able to be used without alteration. However, one problem with this would be the possibility of other programs writing to this inter face which did know about Sideband and which did not set or clear this register properly. This could cause unpredictable results. A partial answer to other programs writing to the interface is that NetBIOS protocol driver will have some indicator to show that Sideband is active and will only check this register if the indicator is set. Any session is owned by a application wllich does not know about Sideband will not have this indicator set, since it would not have been able to set up Sideband at session set up time.
FIG. 8 depicts Sideband session set-up and message passing between workstations A and B according to the present invention. Both workstations A and B have installed NetBIOS
and a NetBIOS application such as LAN Server which are modified to handle Sideband. First, at workstation A, the NetBIOS application initiates a listen Sideband command request for any caller to set-up a session. This indicates that the NetBIOS application is ready to accept a transmission from any caller on Sideband. Next, the NetBIOS
application at workstation B will issue a Sideband call. The Sideband call will result in the normal session initialization sequence where a frame will flow from workstation B to workstation A to request establishing call.
Since the listen command has been issued for Sideband at 210~076 workstation A, the negotiation will take place indicating that Sideband is supported on both sides of the session.
Both workstation A and workstation B at the completion of the negotiation will build a session control block containing the Sideband connectionless headers. On workstation A, the Sideband listen will complete and on workstation B will complete the Sideband call, both of which will indicate to the NetBIOS application that a session has been established with Sideband support by using a return field in a NCB.
Next, FIG. 8 illustrates Sideband data transfer workstation A will issue a receive any which will enable it to receive Sideband or non-Sideband messages. Workstation B issues a Sideband send command on the established session on workstation A the NetBIOS Protocol driver decides that the data fits into one frame and it is on a session that supports Sideband, so the Sideband frame is sent from workstation B to workstation A. At the same time on workstation B, the Sideband send is completed back to the NetBIOS application with an indication that the data was sent on Sideband. On workstatio1l A, the Sideband frame is received and used to comp]ete the receive any command back to the NetBIOS application Oll workstation A. The receive any command will preferably have a completion code indicating that the data was received on a Sideband frame.
Next, on workstation B, another Sideband send is issued to NetBIOS. In this case, the decision is made that this data does not fit in one frame, and this send is rerouted internally in NetBIOS through the normal non-Sideband send path. Non-Sideband paths generally break the message into separate frames and send the frames on non-Sideband frames to workstation A. Workstation A receives these non-Sideband frames then completes a receive any to the NetBIOS
application in worlcstation A with a return code indicating that the data was not received in non-Sideband frames. The NetBIOS Protocol in workstation A then builds an acknowledgement frame for this non-Sideband message and sends it to workstation B. On Workstation B, the NetBIOS
f .
21~4076 Protocol receives the acknowledgement and completes the Sideband send to the NetBIOS application on workstation B
with an indication that the data did not flow Sideband but that the send was successful on non-Sideband.
Once the Sideband control block of connectionless header is built, it is used throughout the session for Sideband data transfer. This is different from the other NetBIOS prior art transfer methods. In session-oriented data transfer, some of the header could be preserved but, as some header parameters varied with every frame of data, the header would have to be rebuilt with every frame. In datagram data trans~er, no header was saved, so the header would also need to be rebuilt with a new datagram. By limiting the amount of information that can be sent Sideband to a data packet that will fit in one frame, the pre-built connectionless header can be preserved throughout the session. If Sideband transmission were allowed on a data packet which would span two or more frames, some alternate means other than header parameters of piecing data packets together must be devised.
In the preferred embodiment, a Sideband request does not require a Sideband respon.se; the converse is also true, a Sideband response may be sent for a non-SB request. There may be some situations in which a response is forced to use non-SB mode when a request has been sent non-SB. If true, the receiver must know if a data packet has been sent non-SB
or Sideband and to have a way to let the LAN Server code in the receiving machine know which way the data packet was sent. If the system keeps track of whether Sideband is enabled between the redirector and server code, it allows the requesting machine to control when the responding system uses Sideband without an explicit enable/disable mechanism.
In the preferred embodiment, Sideband receives are transparent to the LAN Application. A Receive or Receive Any completion may be satisfied by a Sideband or a non-SB
message, and the LAN Application does not necessarily need to know which type of message it was. In other words, any Receive or Receive Any com-nands which are posted will take ' f'~ ~
any message that is received by NetBIOS protocol driver regardless of whether it came across Sideband or not.
It is useful to have a means for NetBIOS protocol driver to indicate to the LAN Application code on which path the data was received i.e., whether it was sent Sideband or not. This signalling could be handled by a register, some bit being set, or by a different return code.
FIG. 9 is a flow diagram of the procedure to determine whether the network is sufflciently reliable to use Sideband. The determination of reliability is made by a particular NetBIOS application. The fact that Sideband does not guarantee delivery of the message will affect different applications differently. For example, a multimedia application in which a high rate of data transfer in depicting full motion video may be relatively unsusceptible to data loss. If a particular frame, say one frame in thirty is missing, it may not be visually perceptible. Even if the frame is missed, it may be no more than a blink on the screen. Nonetheless, for some session-oriented applications, it will make a great deaL of difference whether the message was sent and received.
One example of a session-oriented program which depends on the receipt of messages is the r,AN Server Redirector program depicted in FIG. 9 on workstation A. After LAN Redirector sends out a Sideband message in Step 200 via NetBIOS, the frame gets lost either on its way to the workstation B where the LAN Server server is resident or after LAN Server sends the response back to workstations A in step 202. The LAN
Server Redirector waits for the SMB command response from LAN server server with a particular time out in step 204. If no response is received within the specified period, time-out occurs and the message is resent. The retry of the send may be in Sideband or it may be preferred in non-Sideband as the particular message apparently did not reach its destination in Sideband. Meanwhile, in Step 208, a count is kept of the number of Sideband failures in the session. Once there have been too many Sideband failures, ., according a predetermined number of failures within a certain period of time in Step 210, the Sideband is disabled on the session to the server, in Step 212. A command is issued in Step 214 that Sideband should be disabled on the session in workstation B. Also, the SMB command is sent via a non-Sideband send and Step 216 In Step 218 the Sideband disable is propagated throughout the network and all nodes stop sending Sideband messages to the server. If there have not been too many Sideband failures, the server continues to use Sideband in Step 220.
As illustrated in FIG. 9, certain NetBIOS applications expect an SMB response generated by another NetBIOS
application to their SMB command. In the prior art session-oriented communication, the application would also receive an LCC 2 response and a NetBIOS response, resulting in three responses where one response would do.
In one preferred embodiment, Sideband will be enabled and disabled by the LAN Server or otller Sideband-aware LAN
application. If Sideband is enabLec~ or disabled on the sending system, the LAN applicati OII Wi 1L also issue messages to enable or disable Sideban~l Otl the receiving workstation.
FIGs. lOA-lOC illustrate the machille states in the process flow in FIG. 9 when each machine will notify the NetBIOS
protocol driver on the same system and the LAN Server code on the other system of any challges in enable or disable status of the Sideband code. Also the NetBIOS protocol driver on one system will notify the NetBIOS protocol-driver on the other machine of changes in the enable or disable status of the Sideband code.
Once the requester machine determines that Sideband must be disabled, it will inform the NetBIOS protocol driver on the local machine, in this case the requester machine and then the NetBIOS protocol driver on the local machine will notify the NetBIOS protocol driver on the remote machine, in this case the server machine. The state at this point is illustrated in FIG. lOA.
( The LAN Server Code at the requester machine and the NetBIOS
protocol driver at both the requester and server machines now know that Sideband has been disabled. There is no mechanism for the NetBIOS protocol driver to directly indicate to LAN Server on the server machine that Sideband has been disabled. This information will be acquired by the LAN Server code, however, the next time it attempts to send using Sideband. At this time, the NetBIOS protocol driver will return the error SB_ERR_SB_DISABLED, which will be the LAN Server code's indication to disable Sideband on the server machine. The~NetBIOS protocol driver will then send the data along the non-SB path. The state after the transaction occurs is illustrated in FIG. lOB.
The method for indicating that Sideband has been re-enabled is similar. Once it has been determined that the link is reliable enough to resume using Sideband, the LAN Server code on the requester machine will inform the NetBIOS
protocol driver on the local machine, and then the NetBIOS
protocol driver on the 410cal machine will notify the NetBIOS protocol driver on the remote machine. The state at this point is illustrated in FIG. lOC.
i The next time that the NetBIOS protocol driver on the server machine receives a Sideband packet from the requester machine, the NetBIOS protocol driver will notify the LAN
Server code on the server machine by setting the indicator to indicate that this packet was received on the Sideband path. This will be the LAN Server code's indication that the requester LAN Server code has re-enabled Sideband and that it is now permitted to set the SB_ENABLED indicator on the server machine and to start using Sideband again.
There are several ways for NetBIOS to notify the LAN Server code that Sideband is enabled again. First, NetBIOS protocol driver will change a return code on a return from a receive or receive any command (RCV/RCV_ANY) to indicate that the data was a Sideband receive or not. Second, a bit or flag can be set in the NCB on an SB transfer. Third, NetBIOS
protocol driver would actively send a message that Sideband has been re-enabled. Fourth, NetBIOS protocol driver could provide a Query_SB NCB for LAN Server to periodically check.
Fifth, LAN Server can continue to try Sideband until it stops getting SB_ERR_SB_DISABLED return codes and proceeding as in to send Sideband.
.
There are also two ways to keep track of whether Sideband is enabled between redirector and server code. First, RO
Server gets a NCBDone call and handles and passes the NCB a one call on to the redirector code. It may only be necessary for the RO Server to pass this NCB along to the redirector code if there are some data structures that only are allocated when Sideband is enabled or if there is an action which the redirector needs to do immediately upon enabling of Sideband. Second, the RO Server could set a flag in the NBI structure to indicate Sideband enabled.
If a Sideband message is sent after Sideband has been disabled at the NetBIOS protocol driver level, the NetBIOS
protocol driver will flow the message non-SB, but will return a return code/flag/indicator which will signal that it has been sent non-SB.
This case could occur when the first step of the disabling process described above has occurred, but not the second step. If a Sideband message is not successfully received and responded to in a designated amo~lnt of time, then LAN Server will be generally responsible for resending the message along the non-SB path. LAN Server has error handling code to manage a situation when a response is not received after a message has been sent on the Sideband path. Timers are set for each NCB sent on the Sideband path. LAN Server then checks for a response. If no response is sent within a designated amount of time, then the LAN Server code is responsible for re-sending the NCB along the non-SB path.
When too many failures have occurred on a Sideband session, Sideband will be disabled. LAN Server code is able to keep track of the information about how many packets which were originally sent Sideband had to be resent, and use this info ;~
-210~076 as the basis for the determination that too many failures have occurred using Sideband. In this way calls are not necessary to NetBIOS protocol driver but would require new data structures to keep track of failures on Sideband.
Once it has been decided that Sideband should be disabled, the process described in the discussion above will be implemented to pass the word that Sideband has been disabled.
At some point, Sideband may eventually be re-enabled after being disabled. Generally, LAN Server will also be responsible for the determination when the network is reliable enough to begin using Sideband again. Once this has been decided, the LAN Server code will initiate the enabling process described in the discussion above to start using Sideband again.
LAN Server or another Sideband aware LAN application will set up a table which will contain the NCB control block to use when Sideband is activated. Most of these NCB codes will be the same as the non-SB codes, but the sends will not be the same. It will take 128 bytes to store this table to take into account all possible NCB command codes. When the NCB is about to be sent to NetBIOS protocol driver in SpecSendSMB
in \21\redir\netmpx.asm a test will determine if Sideband is active, and if it is, convert the code to the Sideband code.
The new NCB Codes to be used are:
,- NCB.SEND.SB 0x50 ~~ NCB.CHAIN.SRND.SB Ox51 NCB.SEND.NOACK.SB 0x52 NCB.CHAIN.SEND.NOACK.SB 0x53 NCB.SENDRCV.SB 0x54 NCB.CALL.SB 0x56 NCB.LISTEN.SB Ox57 NCB.CONTROL.SB 0x55 The fields in an NCB are shown in FIG. 11 and discussed in detail in Chapter four of the LAN Technical Reference ,?! ~ 3 r~
(SC30-3383) cited above. All of the Sideband NCBs correspond to their non-Sideband counterparts in that the calling conventions and structures are the same. The return structures are also identical with the following exceptions:
For all SEND's, the Receive Timeout field of the NCB
structure will contain the Sideband return code as explained below.
For all RECEIVE' 9 the Send Timeout field of the NCB
structure will contain the Sideband return code.
The Sideband return code can have the following values.
O Means the frame was sent or received via the Sideband path.
1 Means Sideband was disabled for the session.
2 Means the user had reguested a Sideband send or receive, but a non-Sideband send or receive was executed because the data did not fit into a single frame.
FOR A ~ul~ NETWORK
Background of the Invention This invention relates generally to data processing systems - in an interconnected environment. More particularly, it relates to an improved method for transmitting small packets of data in a data processing system in an interconnected environment.
It is becoming increasingly prevalent to couple a plurality of data processing systems in an interconnected computing environment such as a Local Area Network (LAN) or Wide Area Network (WAN). The net works are becoming increasingly complicated, with several different LAN networks of different protocols coupled together with the data processing systems from multiple vendors in the network. To assure that different network technologies can communicate with each other, most vendors provide capability to interface according to the IEEE and International Standard Organization's standards for Local Area Networks. ISO 8802-2 (IEEE Standard 802.2-1989) Logical 1ink Control Protocol describes the data link layer in a Local Area Network. ISO
8802-3 (IEEE Standard 802.3-1988) describes a bus utilizing CSMA/CD as the access method. ISO 8802-4 (IEEE Standard 802.4-1985) describes a bus utilizing token passing as the access method. ISO 8802-5 (IEEE Standard 802.5-1989) describes a ring utilizing token passing as the access method. ISO 8802-7 describes the ring utilizing a slotted ring as the access method. This family of standards deals with the physical and data link layers as defined by the ISO
open systems interconnection reference model.
The data link layer described in ISO 8802-2 consists of a top or logical link control (LLC) sublayer and a bottom layer or medium access control (MAC) sublayer which is defined to complete the functionality of the data link layer _ _ . ...... _, _ _ . _ _ _ . __ __ ~ . . _ _ _ __ , _ , .
has two LLC protocols for communication between two systems in the network to satisfy a broad range of potential applications. The ISO 8802-2 LLC type 1 protocol is a connectionless protocol with minimum protocol complexity which has no guarantee of delivery to the receivinq system and is described in Section 6 of the ISO standard. This mode is useful when the higher layers, e.g., applications, provide any essential recovery and sequences so they do not need replicating in the data link layer. This type of operation also is useful in applications where it is not essential to guarantee the delivery of every data packet.
The ISO 8802-2 LLC type 2 protocol is a connection-based protocol for guaranteed delivery. This mode includes support of sequence delivery of data link layer units and a comprehensive set of data link layer recovery techniques.
This second type of operation is described in section 7 of the ISO standard. Because many network servers and message transfer interfaces, such as IBM's LAN Server. and NetBIOS., call for session-oriented data transfer between two systems on a network. To track transactions for each client, they are generally forced to use a session-level protocol and the 802.2 type 2 protocol on all data transfers. While this data transfer method can be efficient for large messages, for small messages the performance is relatively poor.
r Brief Description of the Invention It is therefore an object of the invention to increase throughput and decrease response time for transmission of small network packets.
This and other objects of the invention are accomplished by using the knowledge that a network is normally reliable.
Extensions to an LAN Application and an enhanced Protocol driver which include the ISO 8802-2 protocol and the NetBIOS
protocol driver will cooperate in a new form of connectionless, session-oriented communication called the Sideband. In Sideband, header information is stored and reused to increase the throughput and decrease the response time for the transmission of small network packets.
~, 2~04076 At each session start-up time, the LAN Application will communicate with the enhanced IS0 8802-2 protocol driver to determine if they both support the Sideband. Also, the requestor system on which the LAN Application and the enhanced protocol driver are resident will determine if Sideband is supported on the receiving system to which Sideband Communication will be sent. If Sideband is fully supported by both systems, Sideband will be activated for the session.
When it comes time to communicate on a session which has Sideband active, the LAN Application may request that the information is to be sent using the Sideband path. If so, enhanced protocol driver will check to see if the data meets Sideband criteria, e.g., will fit into a single packet and will attempt to send the packet Sideband if it meets the criteria. As Sideband is a connectionless medium, the additional code path needed to set up and track timers and to handle the resend attempts are saved in the protocol. If session-oriented responses are important to the LAN
Application code, it will keep track of a timer which will cause the data to be resent alonct the non-Sideband path if a response is not received within ~ designated amount of time.
For further code path savings, the enhanced protocol driver code will store the header and trailer information for a session. Since the header and trailer information remains constant for all single packets sent across a session in Sideband, the time needed to follow the normal code path needed to fill in this data is eliminated.
Sideband is dependent on a reliable network. In case the network at some points becomes unreliable, procedures are used to track the reliability of the network and to enable and disable Sideband in accordance with the reliability of the network.
Brief De~cription Of The Drawing~
FIG. 1 depicts a typical workstation whlch would be coupled 210407~
to a network environment in accordance with the present invention.
FIG. 2 depicts a plurality of workstations in a network environment according to the present invention.
FIG. 3 depicts the code modules in the memory of a ~ workstation using LAN Server and NetBIOS according to ISO 8802-2 and the present invention.
FIGs. 4A-C depict communication using NetBIOS session oriented, datagram and Sideband communication modes according to ISO 8802-2.
FIGs. 5A-C depict the frame header f.ields for Session, Datagram and Sideband comm~lnication respectively.
FIG. 6 is a flow diagram for the process for establishing the Sideband session.
FIG. 7 is a flow di.agram for sending a message by Sideband.
FIG. 8 depicts Sideband communicatioll between two workstations on the network.
.. ......
FIG. 9 is a flow diagram to determine whether the network is sufficiently reliab]e to use Si.deband FIGs. lOA-C depict disabling and enabling Sideband across a network.
FIG. 11 shows the fields in a Network Control Block (NCB).
Detailed Description of The Invention A representative hardware environment is depicted in FIG. 1, which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units interconnected 210407fi via a system bus 12. The workstation shown in FIG.
includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter 34 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to display device 38.
The preferred embodiment of the s~lbject invention is an IBM~
Personal System/2~ with the IBM OS/2 Operating System~
installed. Detailed descriptions of the hardware and software environment are provided in PS/2 Hardware Interface Technical Reference, SlOG-6457, IBM Corporation (1991), and OS/2 Presentation Manager Programming, SC28-2700, IBM
Corporation (1992). While the invention will be described in terms of this hardware and software, one skilled in the art will recognize that other operating systems and hardware can be supported without undlle experimentation. Also resident on the computer system is the OS/2 LAN System Software support including the software maki ng up the subject invention. The system software llsed in the previous release is described in the following pnhlications available from IBM: IBM Operating System/2 I,oca] Area Network Server Version 2.0 Information an~3 Planllinc3 Guide (G236-0162); IBM
Local Area Network Server Programs (Specification Sheet) (G360-2753); and IBM Local Area Network Technical Reference (SC30-3383).
Interconnected computing environments are becoming much more prevalent. Network environments are becoming more varied, consisting of different LAN technologies, multiple vendors and multiple adapters. There is also a higher performance requirement and a greater need for network management. FIG.
2 is an illustration of a typical computer network environment comprising a plurality of interconnected workstations similar to that shown in FIG 1.
FIG. 2 illustrates a local area network 40 which is preferably a IBM Token Ring, however, it could also be an Ethernet or PC net or other LAN type system. OS/2 requester 42 communicates via LAN 40 to LAN Server server 44 for file sharing, application server database server, print server, communications server and other services. The OS/2 Requester 42 as, might be suspected, runs on the OS/2 2.0 operating system. The DOS Requester 46 communicates by means of Bridge 48 to LAN 40 to request similar .services from the LAN Server server 44. The DOS Requester 46 runs on the DOS Operating System 5Ø The Bridge 48 is used to couple the DOS
Requester 46 and Network Server 50 via Ethernet 51 to the LAN 40. The Netware Server 50 runs on the Novell Netware~
local area network software and provides an example of the level of integration of vendors which is possible in today's local area networks. The OS/2 SNA gateway 52 provides service to the LAN 40 via bus 54 to the other networks which operate on the SNA Protocol. Finally, powerful RISC based workstations such as the RISC System/6000~ 56 can also be coupled to the local area network 40.
FIG. 3 illustrates the architectural block diaqram of the software applications at least a subset of which would be resident in the RAM access memory of a workstation on the LAN. Generally, this software configuration is known as the LAN adapter and Protocol Support (LAPS) consists of the network communication software necessary to support LAN
connectivity. LAPS is a combination of Network Driver Interface Specification (NDIS) compliant protocol drivers, NDIS compliant network adapter drivers, Application Program Interface (API) support software, and configuration and installation software for the drivers. The IBM Network Basic Input/Output System NetBIOS) has been extended to interface to NDIS and to the 802.2 specification.
NetBIOS function is provided by the NetBIOS box 60 and the IBM OS/2 NetBIOS Protocol driver or NetBEUI 62. The NetBIOS
block 60 provides the mapping functions, mapping OS/2 application calls to the NetBEUI Protocol 62. The NetBIOS
Protocol driver 62 takes the NetBEUI mapping or LAN Server 210~076 - or LAN Requester request and processes them according to the NetBIOS Protocol. This protocol is defined in Local Area Network Technical Reference, (SC30-3383-3).
i LAN Server 64 performs file sharing, application server, database server and other similar functions for workstations coupled to the local area network. LAN Requester 66 provides the user access to the functions provided by a LAN Server 64 located at a different workstation in a local area network.
RDS DOS support 70, supports database functions from the database server product part of the Extended Services for OS/2 2Ø This is a NetBIOS application and would pass its messages through NetBIOS 60 before going to the NetBIOS
Protocol driver 62. NetBIOS applications 72 also pass messages directly to NetBIOS 60. There is an advantage in using NetBIOS, rather than the IEEE 802.2 Protocol driver 74 in that the LAN application can be much simpler and it not know all the protocol functions. The IEEE 802.2 Protocol driver 74 performs similar functions as the NetBIOS Protocol driver 62, but according to the IEEE 802.2 Protocol. The NetBIOS Protocol driver 62 has two protocol layers, the NetBIOS protocol layer and the 802.2 Protocol layer. The network protocol drivers 62, 7~ provides the communication between an application and a network adapter driver 92.
Remote Installation Program Load (RIPL) 68 allows a remote initialization of a workstation from the server. SNA-LAN DLC
76 provides an SNA interface to the 802.2 Protocol. SQL L00 interface 78 provides a fastpath for databases to the 802.2 Protocol driver. Among the API's which utilize the SNA-LAN
DLC 76 interface are the SNA gateway 80, the PPC-LU 6.2 API
82, the LU2 API 84 and the LUA API 86. Databases such as remote data services 88, can use the SQL LOO interface 78 to the 802.2 Protocol Driver 74. NDIS 90 is a standardized Medium Access Control (MAC) Interface for network adapter drivers and protocol drivers. NDIS has become an industry standard for network adapters and LAN software to communication with each other. NDIS separates protocol handling from hardware manipulation by defining functions that protocol drivers 62 and 74 and network adapter drivers 92 must provide to each other. NDIS defines specifications - - - : - -210~07~
for network protocol drivers 62, 74, Adapter drivers 92, and the interfaces between the two and a binding process to link the protocol and adapter drivers. Network Adapter Drivers 92 provide the software interface to network adapters 94, such as the Token Ring Ethernet or PC Net Adapters.
Session, Datagram and Sideband NetBIOS data transmission examples are shown in FIGS. 4A, 4B and 4C respectively. Note that Session data transfer receives an acknowledgement response (DATA_ACK) from the receiving node to the initial data packet (DATA_ONLY_LAST), whereas in the both Datagram and Sideband transfer, no acknowledgement takes place, either at the NetBIOS protocol layer or at the 802.2 protocol layer. This is due to the fact that Session transmission uses ISO 8802-2 LLC type 2 transmission services which requires an LLC response, and NetBIOS Session protocol which requires a NetBIOS response. Datagram and Sideband transfer, on the other hand, use ISO 8802-2 LLC
type 1 transmission which does not require an LLC response back from the receiving node. Also, the Datagram and Sideband NetBIOS protoco]s clo not require a NetBIOS
response.
At the NetBIOS protocol level, the session is an association of facilities necessary for establishing, maintaining, performing data transfers and releasing logical connections for communications between stations. The prior art NetBIOS
Session protocol performed these functions exclusively on the logical link connections of ISO 8802-2 Type 2 (connection-oriented) protocol. The Sideband NetBIOS
protocol allows the data transfer function of the session to be performed on ISO 8802-2 Type 1 (connectionless) protocol.
LLC connectionless and connection oriented services are defined in detail in section 2.1 of the ISO 8802-2 standard.
The present invention is preferably embodied in changes to the NetBIOS Protocol Driver 62 and a NetLIOS application such as LAN Server 64 or LAN Requester 66 which make them aware of the Sideband and able to transmit data by the Sideband.
- - -2~04076 FIGs. 5A, 5B and 5C illustrate session-frame, datagram-frame and Sideband frame, header fields respectively. Both session-level and datagram transmission are known in previous versions of netBIOS.
NetBIOS session-level data transfer ~lses NetBIOS send and receive commands for guaranteed delivery of messages. It uses NetBIOS I-frame headers on 802.2 type 2 I-frames for guaranteed delivery. The SESSION Frame Header Fields as shown in FIG. 5A are as follows:
. .
MAC header - Varies with LAN type (IEEE 802.5, 802.3 etc.
LLC header - [ FO FO XX YY ] A normal IEEE 802.2 I
frame, type 2, LLC header.
.
(the remaining fields are in the format of a normal NetBIOS
I-frame header.) NetBIOS Header Length - [ OE 00 ] Specifies a 14-byte NetBIOS header.
NetBIOS Signature - [ FF EF ] Identifies the frame as a NetBIOS frame.
Command Code - 115/16 1 Data -First-Middle or Data-Only-Last Command.
DATAl - No-Ack and Receive - Continue Flags.
DATA2 - Resynk Indicator Xmit Correlator - Piggyback Ack Correlator or O(not used) Rcv Correlator - 2-Byte Correlator from Sender, Used For Acknowledge Destination LSN - [session-specific ]
l-byte destination session number.
Source LSN - [ session-specific ]
l-byte source session number NetBIOS datagram traffic uses NetBIOS datagraphy and broadcast datagram commands to send non-guaranteed messages, ~- - - - --it uses NetBIOS datagram UI headers on top of 802.2 type 1 UI frames. The DATAGRAM Frame Header Fields as shown in FIG.
5B are as follows:
MAC - Varies with LAN type (IEEE 802.5, 802.3 etc.) LLC header - [ FO FO 03 ] A normal IEEE 802.2 UI
frame LLC header, type I.
NetBIOS Header Length - [ 2C 00 ] Specifies a 44-byte NetBIOS
header.
NetBIOS
_ Signature - [ FF EF ~ Identifies the frame as a ~_- ' NetBIOS frame.
Command Code - [ 8, 9 ] Data-Only-La~t command.
Indicates the frame is the last piece of the SEND.
DATAl - [ 00 ] Set to O but not used by the receiver.
DATA2 - [ 00 00 ] Set to O but not used by the receiver.
Xmit Correlator - [ 00 00 ] Set to O but not used by the receiver.
Rcv Correlator - [ 00 00 l Set to O but not used by the receiver.
Destination Name - [ 16-Byte Name of Receiver session number.]
Source Name - l 16-Byte Name of Sender session number]
Sideband uses Sideband sends and normal session receive commands to send non-guaranteed, session-oriented data.
Sideband uses a NetBIOS I-frame header on top of an 802.2 UI
frame on 802.2 type 1 frame with a special field to indicate that it is a Sideband message. The SIDEBAND Frame Header Fields as shown in FIG. 5C as follows:
MAC header - Varies with LAN type (IEEE
AT9-92-092 ll - 802.5, 802.3 etc.~
LLC header - [ FO FO 03 ] A normal IEEE 802.2 UI frame, type l, LLC header.]
SB Signature - I OF] A one-byte signature value which can be checked by the receiving NetBIOS protocol to identify the received frame as a Sideband frame.
(The remaining fields are in the format of a normal NetBIOS
I-frame header.) NetBIOS Header Length - I 00 00 ] Specifies a 14-byte NetBIOS header.
NetBIOS Signature - [ FF EF 1 Identifies the frame as a NetBIOS frame.
' Command Code - [ 16 ] Data-Only-Last command.
Indicates the frame is the last piece of the SEND.
DATAl - 1 00 00 ] Set to O but not used by the receiver.
DATA2 - 1 00 ~~ 1 Set to O but not used by the receiver.
Xmit correlator - 1 00 00 I Set to O but not used by the receiver.
Rcv Correlator - I 00 00 J Set to O but not used by the receiver.
Destination LSN - ¦ session-specific ]
l-byte destination session number Source LSN - Isession-secific]
l-byte source session number.
FIG. 6 is a flow diagram for the process for establishing the Sideband session. The process begins step lOO where NetBIOS is called by a NetBIOS application to establish a session using Sideband. The command to establish a session can either be a Sideband li,sten or a Sideband call. Next, a test is performed to determine whether a Sideband is enabled s~
210407~
locally in step 102. If not, a normal NetBIOS session is established and an error code is returned to the calling application in step 104. To establish a normal NetBIOS
session, the procedures outlined in Chapter 5 of the LAN
Technical Reference (SC30-3383) are followed. If Sideband is enabled locally, the NetBIOS session is initiated. Sideband support is negotiated in Step 106. Establishing a Sideband session is similar to establishing a normal NetBIOS Session in step 104, except that an additional negotiation on a single bit is required for Sideband support. Next, a test is performed to determined whether Sideband is supported remotely in Step 108. If not, the normal NetBIOS session is established in Step 104. If it is supported remotely, the Sideband session control block is built with a connectionless header in steps llO and 112. First, a Medium Access Control (MAC) layer and LCC layer UI Type 1 header and the new Sideband header for that session are built in step 110. Next in step 112, the NDIS frame descriptor is built with immediate data pointers set to the pre-built header built in the previous step Sideband availability c~n be determilled on both ends of a session which is being established. Three methods were discussed to handle this, two of the methods being implemented by the NetBIOS protocol driver, and the third would have to be done by LAN Server. The first method is for the NetBIOS protocol driver code to determine availability at CALL/LISTEN time of the session setup using a new bit, and then to pass the new bit to LAN Server using a return code. Most of the new coding would be in Net Bios, LAN
Server would merely add the code needed to handle the new return code. The second method would be to use a SESSION_ALIVE call, and if a response is received, then Sideband is available. The third method is for LAN Server to use a new SMB protocol to handle the Sideband availability determinations.
Once the Sideband session is established and the Sideband message header is built, NetBIOS is ready to issue a Sideband send command. The process flow for a Sideband Send 210~076 i8 illustrated in the flow diagram in FIG. 7. NetBIOS is called by a NetBIOS application to issue a Sideband send command in step 120. Next, a test is performed to determine whether Sideband is active in this session in Step 122. If not, the Sideband send request is rerouted to a non-Sideband send path in step 124. A save return code is saved so that when the response to the initial message is made, the save return code is returned to indicate that the send request was sent on a non-Sideband path. If Sideband is active on the session, a second test is performed to determine whether the message will fit in one frame in Step 126. If not, the message is rerouted to a non-Sideband send as described in step 124. If the message does fit in one frame, the pre-built Sideband headers as described in Steps 110 and 112 in FIG. 6, are used to issue the frames to the lower level, for example, the NDIS level. Finally, a completion code is returned to LAN Application which requested the Sideband Send in Step 130.
In the preferred embodiment, the network only uses Sideband if the data packet is small, l.e., it-. fits in one Medium Access Control (MAC) frame. The MAC frames are used to communicate off the LAN and are described in the ISO 8802-3, 8802-4, 8802-5, 8802-7 standards. Thls determination could be made by either an app].ication such as the LAN Server code or by the NetBIOS protoco] driver code as modified for the invention. For the L~N Serve1 code to determine the size of the data packet, an inter~ace is established by which the NetBIOS protocol driver wou]d return the maximum space available for data in a network packet. LAN Server code would then subtract from thi.s amount however much space is needed for the SMB and other header information, and then determine if the data to be sent woul.d fit in the remaining storage space. Alternatively and preferably, the enhanced NetBIOS protocol driver code determines the size of the data packet. This eliminates the need for the interface to the LAN Server. It also reduces the decision path to be limited to one place (in the NetBIOS protocol driver) as opposed to at least two places (in the Ring 0 Server and in the Redirector) which would be necessary in the LAN Server code.
~ According to the flow diagram, if enhanced NetBIOS
determines the data will not fit into a single packet, and it had been asked to send the data on the Sideband path, then it will return an error saying the data did not fit in a single buffer. It will then transfer the data along the non-SB path.
If LAN Server code reguests that a piece of data be sent along the Sideband path by the NetBIOS protocol driver, and it is then not sent Sideband, then the NetBIOS protocol driver will notify the sending system and then send the data packet non-Sideband. Three return codes are used to indicate why the data was not sent Sideband. The first will handle the case that Sideband was active, but the data to be sent did not fit into a single MAC packet (SB_ERR_DATA_TOO_LARGE), and the second is for the case that Sideband has been disabled (SB_ERR_SB_DISABLED). The third return code indicates that the MAC layer cannot accept the frame immediately (SB_ERR_MAC_FULL).
A NetBIOS application which is aware of Sideband such as LAN
Server must be able choose when to send a particular data packet using Sideband and will have a means of indicating to the NetBIOS protocol driver which protocol it would like to have used. There are at least three methods for complying with thi 8 requirement:
First and preferably, a new set of different command codes indicate to NetBIOS protocol driver that Sideband should be used are defined. New command codes require the use of five new Network Control Blocks (NCBs), which both LAN Server and NetBIOS protocol driver handle NCB are discussed Chapter 4 of the LAN Technical Reference. To implement the new command codes without adding a test in each code path, a mapping table was created. Before each send of an NCB, the SB_ENABLED flag is checked, and if it is set, the code executes a few instructions to do the mapping. Checking the flag requires a little more memory (2-4 bytes per non-SB
t command), but would require minimal extra code path.
~ AT9-92-092 15 210~6 Second, a unique entry point and interface could be defined from LAN Server to NetBIOS protocol driver. This option is less preferred if the LAN Server and Net BIOS code would therefore require significant code changes in both the LAN
Server and NetBIOS protocol driver code.
Third, a register value as a flag for LAN Server to indicate to NetBIOS protocol driver that Sideband is to be used for this request could be defined. This would seem to be the easiest method to implement. The only changes to the LAN
Server code path would be to check if Sideband was enabled and to set this register appropriately at the time the NCB
command is submitted to NetBIOS protocol driver. The same entry points and command codes will be able to be used without alteration. However, one problem with this would be the possibility of other programs writing to this inter face which did know about Sideband and which did not set or clear this register properly. This could cause unpredictable results. A partial answer to other programs writing to the interface is that NetBIOS protocol driver will have some indicator to show that Sideband is active and will only check this register if the indicator is set. Any session is owned by a application wllich does not know about Sideband will not have this indicator set, since it would not have been able to set up Sideband at session set up time.
FIG. 8 depicts Sideband session set-up and message passing between workstations A and B according to the present invention. Both workstations A and B have installed NetBIOS
and a NetBIOS application such as LAN Server which are modified to handle Sideband. First, at workstation A, the NetBIOS application initiates a listen Sideband command request for any caller to set-up a session. This indicates that the NetBIOS application is ready to accept a transmission from any caller on Sideband. Next, the NetBIOS
application at workstation B will issue a Sideband call. The Sideband call will result in the normal session initialization sequence where a frame will flow from workstation B to workstation A to request establishing call.
Since the listen command has been issued for Sideband at 210~076 workstation A, the negotiation will take place indicating that Sideband is supported on both sides of the session.
Both workstation A and workstation B at the completion of the negotiation will build a session control block containing the Sideband connectionless headers. On workstation A, the Sideband listen will complete and on workstation B will complete the Sideband call, both of which will indicate to the NetBIOS application that a session has been established with Sideband support by using a return field in a NCB.
Next, FIG. 8 illustrates Sideband data transfer workstation A will issue a receive any which will enable it to receive Sideband or non-Sideband messages. Workstation B issues a Sideband send command on the established session on workstation A the NetBIOS Protocol driver decides that the data fits into one frame and it is on a session that supports Sideband, so the Sideband frame is sent from workstation B to workstation A. At the same time on workstation B, the Sideband send is completed back to the NetBIOS application with an indication that the data was sent on Sideband. On workstatio1l A, the Sideband frame is received and used to comp]ete the receive any command back to the NetBIOS application Oll workstation A. The receive any command will preferably have a completion code indicating that the data was received on a Sideband frame.
Next, on workstation B, another Sideband send is issued to NetBIOS. In this case, the decision is made that this data does not fit in one frame, and this send is rerouted internally in NetBIOS through the normal non-Sideband send path. Non-Sideband paths generally break the message into separate frames and send the frames on non-Sideband frames to workstation A. Workstation A receives these non-Sideband frames then completes a receive any to the NetBIOS
application in worlcstation A with a return code indicating that the data was not received in non-Sideband frames. The NetBIOS Protocol in workstation A then builds an acknowledgement frame for this non-Sideband message and sends it to workstation B. On Workstation B, the NetBIOS
f .
21~4076 Protocol receives the acknowledgement and completes the Sideband send to the NetBIOS application on workstation B
with an indication that the data did not flow Sideband but that the send was successful on non-Sideband.
Once the Sideband control block of connectionless header is built, it is used throughout the session for Sideband data transfer. This is different from the other NetBIOS prior art transfer methods. In session-oriented data transfer, some of the header could be preserved but, as some header parameters varied with every frame of data, the header would have to be rebuilt with every frame. In datagram data trans~er, no header was saved, so the header would also need to be rebuilt with a new datagram. By limiting the amount of information that can be sent Sideband to a data packet that will fit in one frame, the pre-built connectionless header can be preserved throughout the session. If Sideband transmission were allowed on a data packet which would span two or more frames, some alternate means other than header parameters of piecing data packets together must be devised.
In the preferred embodiment, a Sideband request does not require a Sideband respon.se; the converse is also true, a Sideband response may be sent for a non-SB request. There may be some situations in which a response is forced to use non-SB mode when a request has been sent non-SB. If true, the receiver must know if a data packet has been sent non-SB
or Sideband and to have a way to let the LAN Server code in the receiving machine know which way the data packet was sent. If the system keeps track of whether Sideband is enabled between the redirector and server code, it allows the requesting machine to control when the responding system uses Sideband without an explicit enable/disable mechanism.
In the preferred embodiment, Sideband receives are transparent to the LAN Application. A Receive or Receive Any completion may be satisfied by a Sideband or a non-SB
message, and the LAN Application does not necessarily need to know which type of message it was. In other words, any Receive or Receive Any com-nands which are posted will take ' f'~ ~
any message that is received by NetBIOS protocol driver regardless of whether it came across Sideband or not.
It is useful to have a means for NetBIOS protocol driver to indicate to the LAN Application code on which path the data was received i.e., whether it was sent Sideband or not. This signalling could be handled by a register, some bit being set, or by a different return code.
FIG. 9 is a flow diagram of the procedure to determine whether the network is sufflciently reliable to use Sideband. The determination of reliability is made by a particular NetBIOS application. The fact that Sideband does not guarantee delivery of the message will affect different applications differently. For example, a multimedia application in which a high rate of data transfer in depicting full motion video may be relatively unsusceptible to data loss. If a particular frame, say one frame in thirty is missing, it may not be visually perceptible. Even if the frame is missed, it may be no more than a blink on the screen. Nonetheless, for some session-oriented applications, it will make a great deaL of difference whether the message was sent and received.
One example of a session-oriented program which depends on the receipt of messages is the r,AN Server Redirector program depicted in FIG. 9 on workstation A. After LAN Redirector sends out a Sideband message in Step 200 via NetBIOS, the frame gets lost either on its way to the workstation B where the LAN Server server is resident or after LAN Server sends the response back to workstations A in step 202. The LAN
Server Redirector waits for the SMB command response from LAN server server with a particular time out in step 204. If no response is received within the specified period, time-out occurs and the message is resent. The retry of the send may be in Sideband or it may be preferred in non-Sideband as the particular message apparently did not reach its destination in Sideband. Meanwhile, in Step 208, a count is kept of the number of Sideband failures in the session. Once there have been too many Sideband failures, ., according a predetermined number of failures within a certain period of time in Step 210, the Sideband is disabled on the session to the server, in Step 212. A command is issued in Step 214 that Sideband should be disabled on the session in workstation B. Also, the SMB command is sent via a non-Sideband send and Step 216 In Step 218 the Sideband disable is propagated throughout the network and all nodes stop sending Sideband messages to the server. If there have not been too many Sideband failures, the server continues to use Sideband in Step 220.
As illustrated in FIG. 9, certain NetBIOS applications expect an SMB response generated by another NetBIOS
application to their SMB command. In the prior art session-oriented communication, the application would also receive an LCC 2 response and a NetBIOS response, resulting in three responses where one response would do.
In one preferred embodiment, Sideband will be enabled and disabled by the LAN Server or otller Sideband-aware LAN
application. If Sideband is enabLec~ or disabled on the sending system, the LAN applicati OII Wi 1L also issue messages to enable or disable Sideban~l Otl the receiving workstation.
FIGs. lOA-lOC illustrate the machille states in the process flow in FIG. 9 when each machine will notify the NetBIOS
protocol driver on the same system and the LAN Server code on the other system of any challges in enable or disable status of the Sideband code. Also the NetBIOS protocol driver on one system will notify the NetBIOS protocol-driver on the other machine of changes in the enable or disable status of the Sideband code.
Once the requester machine determines that Sideband must be disabled, it will inform the NetBIOS protocol driver on the local machine, in this case the requester machine and then the NetBIOS protocol driver on the local machine will notify the NetBIOS protocol driver on the remote machine, in this case the server machine. The state at this point is illustrated in FIG. lOA.
( The LAN Server Code at the requester machine and the NetBIOS
protocol driver at both the requester and server machines now know that Sideband has been disabled. There is no mechanism for the NetBIOS protocol driver to directly indicate to LAN Server on the server machine that Sideband has been disabled. This information will be acquired by the LAN Server code, however, the next time it attempts to send using Sideband. At this time, the NetBIOS protocol driver will return the error SB_ERR_SB_DISABLED, which will be the LAN Server code's indication to disable Sideband on the server machine. The~NetBIOS protocol driver will then send the data along the non-SB path. The state after the transaction occurs is illustrated in FIG. lOB.
The method for indicating that Sideband has been re-enabled is similar. Once it has been determined that the link is reliable enough to resume using Sideband, the LAN Server code on the requester machine will inform the NetBIOS
protocol driver on the local machine, and then the NetBIOS
protocol driver on the 410cal machine will notify the NetBIOS protocol driver on the remote machine. The state at this point is illustrated in FIG. lOC.
i The next time that the NetBIOS protocol driver on the server machine receives a Sideband packet from the requester machine, the NetBIOS protocol driver will notify the LAN
Server code on the server machine by setting the indicator to indicate that this packet was received on the Sideband path. This will be the LAN Server code's indication that the requester LAN Server code has re-enabled Sideband and that it is now permitted to set the SB_ENABLED indicator on the server machine and to start using Sideband again.
There are several ways for NetBIOS to notify the LAN Server code that Sideband is enabled again. First, NetBIOS protocol driver will change a return code on a return from a receive or receive any command (RCV/RCV_ANY) to indicate that the data was a Sideband receive or not. Second, a bit or flag can be set in the NCB on an SB transfer. Third, NetBIOS
protocol driver would actively send a message that Sideband has been re-enabled. Fourth, NetBIOS protocol driver could provide a Query_SB NCB for LAN Server to periodically check.
Fifth, LAN Server can continue to try Sideband until it stops getting SB_ERR_SB_DISABLED return codes and proceeding as in to send Sideband.
.
There are also two ways to keep track of whether Sideband is enabled between redirector and server code. First, RO
Server gets a NCBDone call and handles and passes the NCB a one call on to the redirector code. It may only be necessary for the RO Server to pass this NCB along to the redirector code if there are some data structures that only are allocated when Sideband is enabled or if there is an action which the redirector needs to do immediately upon enabling of Sideband. Second, the RO Server could set a flag in the NBI structure to indicate Sideband enabled.
If a Sideband message is sent after Sideband has been disabled at the NetBIOS protocol driver level, the NetBIOS
protocol driver will flow the message non-SB, but will return a return code/flag/indicator which will signal that it has been sent non-SB.
This case could occur when the first step of the disabling process described above has occurred, but not the second step. If a Sideband message is not successfully received and responded to in a designated amo~lnt of time, then LAN Server will be generally responsible for resending the message along the non-SB path. LAN Server has error handling code to manage a situation when a response is not received after a message has been sent on the Sideband path. Timers are set for each NCB sent on the Sideband path. LAN Server then checks for a response. If no response is sent within a designated amount of time, then the LAN Server code is responsible for re-sending the NCB along the non-SB path.
When too many failures have occurred on a Sideband session, Sideband will be disabled. LAN Server code is able to keep track of the information about how many packets which were originally sent Sideband had to be resent, and use this info ;~
-210~076 as the basis for the determination that too many failures have occurred using Sideband. In this way calls are not necessary to NetBIOS protocol driver but would require new data structures to keep track of failures on Sideband.
Once it has been decided that Sideband should be disabled, the process described in the discussion above will be implemented to pass the word that Sideband has been disabled.
At some point, Sideband may eventually be re-enabled after being disabled. Generally, LAN Server will also be responsible for the determination when the network is reliable enough to begin using Sideband again. Once this has been decided, the LAN Server code will initiate the enabling process described in the discussion above to start using Sideband again.
LAN Server or another Sideband aware LAN application will set up a table which will contain the NCB control block to use when Sideband is activated. Most of these NCB codes will be the same as the non-SB codes, but the sends will not be the same. It will take 128 bytes to store this table to take into account all possible NCB command codes. When the NCB is about to be sent to NetBIOS protocol driver in SpecSendSMB
in \21\redir\netmpx.asm a test will determine if Sideband is active, and if it is, convert the code to the Sideband code.
The new NCB Codes to be used are:
,- NCB.SEND.SB 0x50 ~~ NCB.CHAIN.SRND.SB Ox51 NCB.SEND.NOACK.SB 0x52 NCB.CHAIN.SEND.NOACK.SB 0x53 NCB.SENDRCV.SB 0x54 NCB.CALL.SB 0x56 NCB.LISTEN.SB Ox57 NCB.CONTROL.SB 0x55 The fields in an NCB are shown in FIG. 11 and discussed in detail in Chapter four of the LAN Technical Reference ,?! ~ 3 r~
(SC30-3383) cited above. All of the Sideband NCBs correspond to their non-Sideband counterparts in that the calling conventions and structures are the same. The return structures are also identical with the following exceptions:
For all SEND's, the Receive Timeout field of the NCB
structure will contain the Sideband return code as explained below.
For all RECEIVE' 9 the Send Timeout field of the NCB
structure will contain the Sideband return code.
The Sideband return code can have the following values.
O Means the frame was sent or received via the Sideband path.
1 Means Sideband was disabled for the session.
2 Means the user had reguested a Sideband send or receive, but a non-Sideband send or receive was executed because the data did not fit into a single frame.
3 Means the user had requested a Sideband send or receive, but a non-Sideband send or receive was executed because the MAC O~ueue was full.
Below is a list of the SMB commands noting which are preferably used in LAN Server code in Sideband. Other SMB
commands will be sent in the future.
SMB OK for Sideband ___ _______________ SMBmkdir SMBrmdir SMBopen SMBcreate SMBclose SMBflush SMBunlink SMBmv SMBgetatr Yes SMBsetatr Yes SMBread Yes SMBwrite Yes SMBlock SMB~nlock SMBctemp SMBmknew SMBchkpth Yes SMBexit SMBlseek Yes SMBtcon SMBtdi S
SMBnegprot SMBdskattr Yes SMBsearch SMBsplopen SMBsplwr j SMBsplclose SMB Bp lretq SMBlockread SMBwriteunlock i SMBreadBraw SMBreadBmpx SMBreadBs SMBwriteBraw SMBwriteBmpx SMBwriteBs SMBwriteC
SMBsetattrE Yes SMBgetattrE Yes SMBlockingX
SMBtrans SMBtranss SMBioctl SMBioctls SMBcopy SMBmove SMBecho M _ SMBwriteclose SMBopenX
--- SMBreadX Yes -~ SMBwriteX Yes SMBcloseTD
SMBtrans2 SMBtranss2 SMBfindclose SMBfindnclose SMBSessSetup SMBulogoff SMBTConX
SMBfind SMBfunique SMBfclose SMBf2close While the invention has been described with respect to particular embodiments above, it will be understood by those skilled in the art that modifications may be made without departing from the spirit and scope of the present invention. These embodiments are for purposes of example and illustration only and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims.
Below is a list of the SMB commands noting which are preferably used in LAN Server code in Sideband. Other SMB
commands will be sent in the future.
SMB OK for Sideband ___ _______________ SMBmkdir SMBrmdir SMBopen SMBcreate SMBclose SMBflush SMBunlink SMBmv SMBgetatr Yes SMBsetatr Yes SMBread Yes SMBwrite Yes SMBlock SMB~nlock SMBctemp SMBmknew SMBchkpth Yes SMBexit SMBlseek Yes SMBtcon SMBtdi S
SMBnegprot SMBdskattr Yes SMBsearch SMBsplopen SMBsplwr j SMBsplclose SMB Bp lretq SMBlockread SMBwriteunlock i SMBreadBraw SMBreadBmpx SMBreadBs SMBwriteBraw SMBwriteBmpx SMBwriteBs SMBwriteC
SMBsetattrE Yes SMBgetattrE Yes SMBlockingX
SMBtrans SMBtranss SMBioctl SMBioctls SMBcopy SMBmove SMBecho M _ SMBwriteclose SMBopenX
--- SMBreadX Yes -~ SMBwriteX Yes SMBcloseTD
SMBtrans2 SMBtranss2 SMBfindclose SMBfindnclose SMBSessSetup SMBulogoff SMBTConX
SMBfind SMBfunique SMBfclose SMBf2close While the invention has been described with respect to particular embodiments above, it will be understood by those skilled in the art that modifications may be made without departing from the spirit and scope of the present invention. These embodiments are for purposes of example and illustration only and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims.
Claims (24)
1. In a computer local area network, a system for communicating in a session between a first and a second application in a first and second computer system, respectively, comprising:
means for establishing a session between the first and second applications in which a plurality of messages may be passed;
means for sending a first set of messages in the session in a first protocol which is both session oriented and connectionless, the first set of messages meeting a set of criteria; and means for sending a second set of messages in the session in a second protocol which is both session oriented and connection oriented, the second set of messages being the messages in the session which do not meet the set of criteria and thus cannot be sent in the first protocol.
means for establishing a session between the first and second applications in which a plurality of messages may be passed;
means for sending a first set of messages in the session in a first protocol which is both session oriented and connectionless, the first set of messages meeting a set of criteria; and means for sending a second set of messages in the session in a second protocol which is both session oriented and connection oriented, the second set of messages being the messages in the session which do not meet the set of criteria and thus cannot be sent in the first protocol.
2. The system as recited in claim 1 which further comprises means for determining whether the first protocol is supported by both applications in the session prior to sending messages in the first protocol.
3. The system as recited in claim 1 wherein one criterion needed to send messages by the first protocol is that the local area network is sufficiently reliable and which further comprises:
means for determining whether the local area network is sufficiently reliable to send messages by the first protocol; and means responsive to a determination that the local area network is not sufficiently reliable for categorizing all messages in the session as belonging to the second set of messages to be sent in the second protocol.
means for determining whether the local area network is sufficiently reliable to send messages by the first protocol; and means responsive to a determination that the local area network is not sufficiently reliable for categorizing all messages in the session as belonging to the second set of messages to be sent in the second protocol.
4. The system as recited in Claim 1 wherein the requesting means is contained in a local area network application and which further comprises:
means for requesting that the first protocol be used for messages in the session;
means for directing a message which does not meet the set of criteria to the means for sending messages via the second protocol; and means for informing the requesting means when a message is sent in the second protocol.
means for requesting that the first protocol be used for messages in the session;
means for directing a message which does not meet the set of criteria to the means for sending messages via the second protocol; and means for informing the requesting means when a message is sent in the second protocol.
5. The system as recited in claim 3 which further comprises means for disabling the means for sending messages in the first protocol if the local area network is not sufficiently reliable thereby sending all messages in the session by the second protocol.
6. In a computer local area network, a method for communicating in a session between a first and a second application in a first and second computer system respectively, comprising the steps of:
establishing a session between the first and second applications in which a plurality of messages may be passed;
sending a first set of messages in the session in a first protocol which is both session oriented and connectionless, the first set of messages meeting a set of criteria; and sending a second set of messages in the session in a second protocol which is both session oriented and connection oriented, the second set of messages being the messages in the session which do not meet the set of criteria and thus cannot be sent in the first protocol.
establishing a session between the first and second applications in which a plurality of messages may be passed;
sending a first set of messages in the session in a first protocol which is both session oriented and connectionless, the first set of messages meeting a set of criteria; and sending a second set of messages in the session in a second protocol which is both session oriented and connection oriented, the second set of messages being the messages in the session which do not meet the set of criteria and thus cannot be sent in the first protocol.
7. The method as recited in claim 6 which further comprises the step of determining whether the first protocol is supported by both applications in the session prior to sending messages in the first protocol.
8. The method as recited in claim 6 wherein one criterion needed to send messages by the first protocol is that the local area network is sufficiently reliable and which further comprises the step of determining whether the local area network is sufficiently reliable to send messages by the first protocol.
9. The method as recited in claim 6 wherein a requesting step is performed by a local area network application and which further comprises the steps of:
requesting that the first protocol be used for messages in the session;
directing a message which does not meet the set of criteria to a means for sending messages via the second protocol; and informing a requesting means when a message is sent in the second protocol.
requesting that the first protocol be used for messages in the session;
directing a message which does not meet the set of criteria to a means for sending messages via the second protocol; and informing a requesting means when a message is sent in the second protocol.
10. The method as recited in claim 8 which further comprises the step of disabling a means for sending messages in the first protocol if the local area network is not sufficiently reliable thereby sending all messages in the session by the second protocol.
11. In a computer local area network, a computer for communicating in a session between a first and a second application in a first and second computer system respectively, comprising:
means for establishing a session between the first and second applications in which a plurality of messages may be passed;
means for sending a first set of messages in the session in a first protocol which is both session oriented and connectionless, the first set of messages meeting a set of criteria; and means for sending a second set of messages in the session in a second protocol which is both session oriented and connection oriented, the second set of messages being the messages in the session which do not meet the set of criteria and thus cannot be sent in the first protocol.
means for establishing a session between the first and second applications in which a plurality of messages may be passed;
means for sending a first set of messages in the session in a first protocol which is both session oriented and connectionless, the first set of messages meeting a set of criteria; and means for sending a second set of messages in the session in a second protocol which is both session oriented and connection oriented, the second set of messages being the messages in the session which do not meet the set of criteria and thus cannot be sent in the first protocol.
12. In a network as recited in claim 11 which further comprises means for determining whether the first protocol is supported in a current computer session.
13. In a network as recited in claim 11 wherein one criterion needed to send messages by the first protocol is that the local area network is sufficiently reliable and which further comprises:
means for determining whether the local area network is sufficiently reliable to send messages by the first protocol;
and means responsive to a determination that the local area network is not sufficiently reliable for categorizing all messages in the session as belonging to the second set of messages to be sent in the second protocol.
means for determining whether the local area network is sufficiently reliable to send messages by the first protocol;
and means responsive to a determination that the local area network is not sufficiently reliable for categorizing all messages in the session as belonging to the second set of messages to be sent in the second protocol.
14. In a network as recited in claim 12 which further comprises;
means for requesting that the first protocol be used for messages in the session;
means for directing a message which does not meet the set of criteria to the means for sending messages via the second protocol; and means for informing the requesting means when a message is sent in the second protocol.
means for requesting that the first protocol be used for messages in the session;
means for directing a message which does not meet the set of criteria to the means for sending messages via the second protocol; and means for informing the requesting means when a message is sent in the second protocol.
15. In a network as recited in claim 13 which further comprises means for disabling the means for sending messages in the first protocol if the local area network is not sufficiently reliable thereby sending all messages in the session by the second protocol.
16. The system as recited in claim 1 which further comprises:
means for building a predefined, invariant set of header information for the first protocol for the session;
means for storing the header information for the first protocol, and, means for retrieving the header information for each of the first set of messages to be sent by the first protocol in the session.
means for building a predefined, invariant set of header information for the first protocol for the session;
means for storing the header information for the first protocol, and, means for retrieving the header information for each of the first set of messages to be sent by the first protocol in the session.
17. The method as recited in claim 6 which further comprises the steps of:
building a predefined, invariant set of header information for the protocol for the session;
storing the header information for the first protocol;
and, retrieving the header information when a message is to be sent by the first protocol in the session.
building a predefined, invariant set of header information for the protocol for the session;
storing the header information for the first protocol;
and, retrieving the header information when a message is to be sent by the first protocol in the session.
18. In a network as recited in claim 11 which further comprises:
means for building a predefined, invariant set of header information for the first protocol for a particular computer session;
means for storing the header information for the first protocol; and, means for retrieving the header information when a message is to be sent by the protocol.
means for building a predefined, invariant set of header information for the first protocol for a particular computer session;
means for storing the header information for the first protocol; and, means for retrieving the header information when a message is to be sent by the protocol.
19. The system as recited in claim 1 which further comprises:
means for storing a message sent in the first protocol at the first computer system; and responsive to a determination by the first application that the first message was apparently not received at the second computer system, means for requesting that the data be sent in a message in the second protocol.
means for storing a message sent in the first protocol at the first computer system; and responsive to a determination by the first application that the first message was apparently not received at the second computer system, means for requesting that the data be sent in a message in the second protocol.
20. The system as recited in claim 1, wherein one criterion of the set of criteria is whether a message can fit within one frame of the first protocol, and wherein, in the session, messages which can fit in one frame are transmitted in the first protocol and messages which require more than one frame are transmitted in the second protocol.
21. The system as recited in claim 1, wherein one criterion of the set of criteria is a message type of prospective messages, and wherein, in the session, messages of a first set of message types are transmitted in the first protocol and messages of a second set of message types are transmitted in the second protocol.
22. The method as recited in claim 6 which further comprises:
storing a message sent in the first protocol at the first computer system;
responsive to a determination by the first application that the first message was apparently not received at the second computer system, requesting that the data be sent in a message in the second protocol; and transmitting the data in a second protocol in the first session with the second set of messages over the local area network.
storing a message sent in the first protocol at the first computer system;
responsive to a determination by the first application that the first message was apparently not received at the second computer system, requesting that the data be sent in a message in the second protocol; and transmitting the data in a second protocol in the first session with the second set of messages over the local area network.
23. The method as recited in claim 6, wherein one criterion of the set of criteria is whether a message can fit within one frame of the first protocol, and wherein, in the session, messages which can fit in one frame are transmitted in the first protocol and messages which require more than one frame are transmitted in the second protocol.
24. The method as recited in claim 6, wherein one criterion of the set of criteria is a message type of prospective messages, and wherein in the first session, messages of a first set of message types are sent in the first protocol and messages of a second set of message types are transmitted in the second protocol.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US930,585 | 1986-11-13 | ||
| US93058592A | 1992-08-14 | 1992-08-14 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2104076A1 CA2104076A1 (en) | 1994-02-15 |
| CA2104076C true CA2104076C (en) | 1999-05-18 |
Family
ID=25459485
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002104076A Expired - Fee Related CA2104076C (en) | 1992-08-14 | 1993-08-13 | Session oriented connectionless data transfer for a computer network |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5675740A (en) |
| EP (1) | EP0586129B1 (en) |
| JP (1) | JPH07117929B2 (en) |
| CA (1) | CA2104076C (en) |
| DE (1) | DE69331297T2 (en) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2737031B1 (en) * | 1995-07-21 | 1997-08-14 | Bull Sa | METHOD FOR TRANSFERRING DATA IN A MULTINODAL COMPUTER SYSTEM |
| US5958015A (en) * | 1996-10-29 | 1999-09-28 | Abirnet Ltd. | Network session wall passively listening to communication session, with use of access rules, stops further communication between network devices by emulating messages to the devices |
| US6070199A (en) * | 1996-11-13 | 2000-05-30 | Extended Systems, Inc. | Apparatus to connect a client computer to a computer data network |
| US5958053A (en) * | 1997-01-30 | 1999-09-28 | At&T Corp. | Communications protocol with improved security |
| US6131117A (en) * | 1997-12-29 | 2000-10-10 | Cisco Technology, Inc. | Technique for correlating logical names with IP addresses on internetworking platforms |
| EP1011226A1 (en) * | 1998-12-17 | 2000-06-21 | Alcatel | Data traffic policing method and device and a telecommunication network including such a device |
| US6532241B1 (en) | 1999-05-20 | 2003-03-11 | Cisco Technology, Inc. | Method and apparatus for determining SNA sessions using various protocols for transport based on filter criteria |
| US6490618B1 (en) | 1999-05-20 | 2002-12-03 | Cisco Technology, Inc. | Method and apparatus for SNA/IP correlation in a mixed APPN and DLSW network |
| US6571272B1 (en) | 1999-05-20 | 2003-05-27 | Cisco Technology, Inc. | Method and apparatus for SNA/IP correlation with multiple DSW peer connections |
| US6430595B1 (en) | 1999-05-20 | 2002-08-06 | Cisco Technology, Inc. | Method and apparatus for establishing a database used for correlating information gathered via SNMP |
| GB0003389D0 (en) * | 2000-02-14 | 2000-04-05 | Symbian Ltd | Wireless information device running multiple interactive applications |
| US7080150B1 (en) * | 2000-04-10 | 2006-07-18 | Rockwell Automation Technologies, Inc. | Pointbus architecture and automatic sequential addressing protocol |
| US7228363B1 (en) | 2000-04-05 | 2007-06-05 | Rockwell Automation Technologies, Inc. | Pointbus architecture and automatic sequential addressing |
| US7493429B2 (en) * | 2003-07-08 | 2009-02-17 | Microsoft Corporation | Communication of information via a side-band channel, and use of same to verify positional relationship |
| US9519600B2 (en) | 2011-03-04 | 2016-12-13 | Microsoft Technology Licensing, Llc | Driver shimming |
| US9003363B2 (en) * | 2011-03-21 | 2015-04-07 | Microsoft Technology Licensing, Llc | Device flags |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4996685A (en) * | 1989-04-10 | 1991-02-26 | Bell Communications Research, Inc. | Technique for dynamically changing an ISDN connection during a host session |
| US5163131A (en) * | 1989-09-08 | 1992-11-10 | Auspex Systems, Inc. | Parallel i/o network file server architecture |
| US5224095A (en) * | 1990-01-30 | 1993-06-29 | Johnson Service Company | Network control system and method |
| JPH03235555A (en) * | 1990-02-13 | 1991-10-21 | Hitachi Ltd | Data communication equipment and data communication system |
| US5202921A (en) * | 1991-04-01 | 1993-04-13 | International Business Machines Corporation | Method and apparatus for authenticating users of a communication system to each other |
-
1993
- 1993-07-23 JP JP5202092A patent/JPH07117929B2/en not_active Expired - Fee Related
- 1993-08-13 CA CA002104076A patent/CA2104076C/en not_active Expired - Fee Related
- 1993-08-16 EP EP93306431A patent/EP0586129B1/en not_active Expired - Lifetime
- 1993-08-16 DE DE69331297T patent/DE69331297T2/en not_active Expired - Fee Related
-
1994
- 1994-08-16 US US08/291,312 patent/US5675740A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP0586129A2 (en) | 1994-03-09 |
| EP0586129A3 (en) | 1995-01-25 |
| DE69331297D1 (en) | 2002-01-24 |
| US5675740A (en) | 1997-10-07 |
| CA2104076A1 (en) | 1994-02-15 |
| EP0586129B1 (en) | 2001-12-12 |
| JPH07117929B2 (en) | 1995-12-18 |
| JPH07168774A (en) | 1995-07-04 |
| DE69331297T2 (en) | 2002-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2104076C (en) | Session oriented connectionless data transfer for a computer network | |
| US5526483A (en) | Fast network file system running over a hybrid connectionless transport | |
| EP0249035B1 (en) | Adaptive session-level pacing | |
| US5265239A (en) | Method for remotely accessing service programs of a local processing system supporting multiple protocol stacks and multiple device drivers | |
| JP2698336B2 (en) | Node used in local area network for digital data processing system | |
| EP0464014A2 (en) | Communications systems using a fault tolerant protocol | |
| US5165020A (en) | Terminal device session management protocol | |
| US5187708A (en) | Communication device for layered protocols | |
| US20080049617A1 (en) | System for fine grained flow-control concurrency to prevent excessive packet loss | |
| CN103636181A (en) | Transporting operations of arbitrary size over remote direct memory access | |
| EP2274898B1 (en) | Method for enabling faster recovery of client applications in the event of server failure | |
| CN109217983B (en) | Industrial Internet of things operation terminal communication protocol design method | |
| US20080062899A1 (en) | Method for Data Transmission Between Devices in a Network | |
| JP3608905B2 (en) | Data communication system and data communication method | |
| US8266253B2 (en) | Server system and event message transmission method therefor, client terminal and connection method and program therefor, and recording medium | |
| CN113992740B (en) | Middleware based on autonomous control and data transmission method | |
| EP1575236B1 (en) | Connectivity confirmation method for network storage device and host computer | |
| JP4006444B2 (en) | Communication of status information on the network | |
| AU718251B2 (en) | Transmission line duplexing processing method and apparatus thereof, and recording medium for recording its processing procedure | |
| JP4123712B2 (en) | Communication processing method and recording medium on which communication processing program is recorded | |
| US11570257B1 (en) | Communication protocol, and a method thereof for accelerating artificial intelligence processing tasks | |
| JPH0964871A (en) | Network management system | |
| KR100460087B1 (en) | Method for controlling a data traffic each of task in data transmit and receive | |
| JPH07210485A (en) | Application proces communication method between information processors and information processor using the same | |
| JP2002290442A (en) | Communication device, program, information recording medium, and communication control method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |