WO1997041674A2 - Packet filtering based on socket or application identification - Google Patents

Packet filtering based on socket or application identification Download PDF

Info

Publication number
WO1997041674A2
WO1997041674A2 PCT/US1997/007271 US9707271W WO9741674A2 WO 1997041674 A2 WO1997041674 A2 WO 1997041674A2 US 9707271 W US9707271 W US 9707271W WO 9741674 A2 WO9741674 A2 WO 9741674A2
Authority
WO
WIPO (PCT)
Prior art keywords
packets
packet
priority
data
socket
Prior art date
Application number
PCT/US1997/007271
Other languages
French (fr)
Other versions
WO1997041674A3 (en
Inventor
James Stuart Binder
Paul James Sidenblad
Roman Gabriel Baker
Glenn William Connery
Original Assignee
3Com Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 3Com Corporation filed Critical 3Com Corporation
Priority to AU28206/97A priority Critical patent/AU2820697A/en
Publication of WO1997041674A2 publication Critical patent/WO1997041674A2/en
Publication of WO1997041674A3 publication Critical patent/WO1997041674A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433Allocation of priorities to traffic types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/625Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/6255Queue scheduling characterised by scheduling criteria for service slots or service orders queue load conditions, e.g. longest queue first
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/6285Provisions for avoiding starvation of low priority queues
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Definitions

  • the current invention relates to the field of electronic circuits. More particularly, the current invention relates to transmission of information between digital devices over a communications medium.
  • the present invention relates to the field of data communication over a computer network.
  • the present invention will be described with reference to a particular types of computer networks, operating systems, and network interfaces. This should not be taken to limit the invention, and it will be apparent to those of skill in the art that the invention has applications in many different types of computer networks.
  • FIG. 1 shows a simplified block diagram of a layered protocol suite as might exist between a personal computer 10 and a server computer 20 communicating via a network 15, such as two Windows-compatible type computers in an office environment running over a LAN.
  • a network 15 such as two Windows-compatible type computers in an office environment running over a LAN.
  • such a system can be thought of as comprising four semi-independent layers running on each computer.
  • a top layer, layer 4 is the application layer.
  • the application layer generally is occupied by software running on the central processor of computer 10. This software might include video conferencing software, e-mail software, the file system, or any other software that accesses network 15.
  • the application layer 4 on computer 10 communicates data, such as a video conferencing signal, with an application layer on computer 20, by passing that data down through the protocol stack on computer 10 to the lowest layer, layer 1.
  • Layer 1 provides a physical connection to the network and sends the data to the layer 1 device on computer 20, which then passes the data back up to its application layer.
  • Protocol layer 3 includes software necessary to perform high level network functions such as accepting a data file from an application layer, dividing that file into packets, and attaching to those packets source and destination address information so that packets can be effectively transmitted over the network.
  • Some examples of different protocol layer software are TCP/IP or IPX.
  • the protocol layer communicates with an adapter driver layer 2 .
  • Layer 2 generally includes software for interfacing between adapter 1 and the protocol layer 3.
  • layer 2 is generally low level software whose primary purpose is to act as the interface between the protocol layer and the particular adapter hardware that is connected to or a part of computer system 10.
  • layer 2 software does not examine the contents or address of any data passing through it, but merely formats that data for the particular adapter to place on the network.
  • driver layer software are NDIS2 or ODl.
  • Adapter 1 is generally thought of as a piece of hardware for communicating signals over the network media. Adapter 1 will have different configurations depending on whether the network media is a co-axial cable, twisted-pair wire, fiber optic cable, or radio waves.
  • the adapter may be a plug in board that connects to computer 10's system bus. Once adapter 1 receives a packet of data to be transmitted over network 15, it sends a packet over network 15 which delivers it to an adapter IA in addressed computer 20. Once data reaches address computer 20, adapter IA passes the packet up the layered stack first to driver layer 2A, then to protocol layer 3A, which then passes to application layer 4A.
  • An adapter generally includes circuitry and connectors for communication over a network medium and translates data from the digital form used by the computer circuitry a form that may be transmitted over a medium, such as a waveform.
  • a driver is a set of instructions resident on a device that allows the device to accomplish various tasks as defined by different network protocols.
  • Drivers are generally software programs stored on the computer in a manner that allows the drivers to be modified without modifying other hardware. In a layered network system such as shown in Fig. 1, various networking tasks are tightly defined and performed at various network layers.
  • driver 2 receives packets of data and forwards them immediately to adapter 1 without examining the contents of the packets of data and without ever changing any of the contents of the packets of data.
  • Driver 2 essentially exists to be an interface between a wide variety of different hardware equipment that may be provided as adapter 1 and the limited number of different network protocols 3 that might be supported by computer system 10. In prior art systems, driver 1 simply sends each packet as it receives it or sends packets in a strict FIFO order where the first packet received from protocol 3 is the first packet sent out to adapter 1 and over the network.
  • the layered system shown in Fig. 1 has worked well in network environments where a majority of network traffic consists of text or computer instructions which do not have particular time-critical requirements and where a computer, such as 10, only allowed one application to access the network at a time.
  • the first is the wide-spread use of socket capable protocols and operating systems in networked environments.
  • a socket system multiple applications running simultaneously on computer 10 can simultaneously send and receive data on network 15.
  • Protocol layer 3 keeps track of for which application a particular data packet is destined by assigning different socket numbers. Socket numbers are requested by applications from protocol layer 3. All data packets sent and received include this number in their headers and thus can be delivered to the right application. The location of the socket identification within the packet is determined by the packet's network protocol.
  • What is needed is a method and apparatus allowing a computer system such as 10 to send real-time data on a network at a higher priority than non-time-critical data and that requires minimal modification to other network hardware or software.
  • the present invention is an adapter driver for use with a network adapter card designed to recognize an identification field from an application layer program and to assign special handling or fil tering to packets received from said application program based on the identification code.
  • this filtering includes assigning a priority to individual packets.
  • a driver assigns one of two priorities: a high priority (HP) or a low priority (LP) . With the assignment of priority, a driver according to the present invention can manage and determine in what order packets are passed to an adapter 1 such that high priority packets are transmitted on the network before low priority packets are transmitted on the network.
  • a driver according to the invention may also change data in a packet's header, thereby identifying special handling indications of said packet to other communications devices in a network.
  • a driver according to the invention may detect a high priority bit in a received packet's header and thereby deliver that packet to the layer 3 protocol ahead of other received packets.
  • a driver is designed to operate in a computer system which can function with a number of different network protocols.
  • the driver includes instructions allowing it to read a network protocol identifier from a packet of data and then to determine the source and destination address from said packet based on the protocol used to encode said packet.
  • An example of one type of system in which the invention may be used is the Windows(TM) operating system, developed and sold by Microsoft(TM) Corporation.
  • Windows operating system applications communicating data to a network identify packets of data with a socket identification. The location of this socket identification within the packet is determined by the packet's network protocol. (In other operating systems, the name for what Window's calls a socket is a port . )
  • a driver In a Windows embodiment, a driver according to the invention reads a packet protocol and from the packet protocol determines the location of a socket identifier. The driver then reads the socket identifier and from it determines the priority of a packet. According to a specific embodiment, packet priority may be based on assigning particular ranges of socket identifiers to particular priorities. Such assignments may be stored in a configuration file on a computer such as computer 10 to be read by the adapter driver at startup.
  • a further example of an environment in which the invention may be employed is the Apple operating system.
  • ar- " ications also assign an identifier to every packet o.. ⁇ ta that is sent to the protocol layer.
  • An adapter driver may include one or more priority transmit queues. These queues, according to one embodiment, are established by the driver in computer 10's main system memory. According to a different embodiment, these queues may be placed in a dedicated memory on the adapter card. According to still another embodiment, a driver may handle high priority packets by interacting directly with memory on the adaptor card and without using priority queues. Where a driver interacts with just one priority queue, the driver includes control means allowing it to place packets at any location in the queues depending on the packet's priority. Where a driver interacts with multiple queues, a packet is located within a queue indicating that packet's priority.
  • an adapter driver according to the invention may be implemented entirely in software and may be designed to run on existing computer systems with existing higher layer protocol drivers and existing adapters.
  • the advantages of the invention may be achieved by modifying only the adapter driver software on a computer such as 10, which is a relatively inexpensive investment to gain the performance benefits of the invention.
  • This software may be embodied in computer readable executable instructions written onto a fixed medium such as a disk, for distribution to individual computer systems either via removeable or fixed disks or over a transmission medium.
  • the invention may be used in conjunction with other modified network software and hardware to achieve further enhancements in performance.
  • modified network elements could include network switching devices that recognize a priority field set by an adapter driver according to the invention and that provide special handling for high priority packets.
  • a driver according to the invention is optimized to run on a modified adapter card which is designed to recognize and provide special handling for high priority packets.
  • the essential technique of the invention includes using an adaptor driver to examine higher layer information in a packet in order to mark the packet for various special handling.
  • this special handling could include encryption, compression, or security blocking.
  • This special handling is distinct from prior art handling of network data because it is done on a packet by packet basis by the adaptor driver layer of the protocol. The present invention is intended to encompass these variations.
  • Fig. 1 is a diagram illustrating a layered network protocol of a type in which the present invention may be effectively employed.
  • Fig. 2 is a block diagram of a computer system and an adapter with a driver according to an embodiment of the present invention.
  • Fig. 3 is a diagram of an example of a packet format which may be effectively handled by the present invention.
  • Fig. 4 is a flow chart of a method of the driver for special handling of the packets according to the present invention.
  • Fig. 5 is a flow chart of a method by which a driver according to the present invention sends packets to an adapter.
  • Fig. 6 is a flow chart of a method by which a driver according to the present invention receives and buffers low priority packets.
  • Fig. 7 is a block diagram of a computer system with an ability to read a computer readable medium allowing the system to operate in accordance with the invention.
  • Fig. 8 shows a system block diagram of computer system 10 used to execute the software of the present invention.
  • Fig. 2 illustrates a computer system 10 containing an adapter 1, an adapter driver 2 according to an embodiment the invention, a protocol layer 3, and application layer 4.
  • Driver 2 has associated with it a protocol detection algorithm (PDA) 50, a high priority transmit queue (HPTXQ) 55, and a low priority transmit queue (LPTXQ) 60.
  • PDA protocol detection algorithm
  • HPTXQ high priority transmit queue
  • LPTXQ low priority transmit queue
  • driver 2 also has associated with it an adapter FIFO transmit list 65 and a low priority receive queue (LPRXQ) 70.
  • Adapter 1 has associated with it an adapter transmit FIFO 110 and an adapter receive FIFO 115. Adapter 1 communicates packets through driver 2 to computer system 10 and transmits and receives packets from network 15.
  • Fig. 3 illustrates an example of a network protocol packet which may be effectively handled by an adapter driver according to the present invention.
  • Fig. 3 illustrates a packet 200, containing packet header 202.
  • Packet header 202 contains, a protocol identifier 210, a source socket identifier 204, a source address 206, a destination socket identifier 208, and a destination address 210.
  • packet header 202 may also contain a locally administered bit 212 which is used by an embodiment of the present invention to indicate special handling of the packet in the network 15.
  • the present invention may also determine the sockets of packets where not every packet includes a socket identification, such as UDP protocol packets.
  • a driver 2 according to the invention, maintains a table of UDP identifiers along with the socket to which a particular UDP connection is assigned.
  • Fig. 4 illustrates a flow chart of the operation of adapter driver 2 illustrating the method of the special handling of packets based on their source socket or their destination socket address according to an embodiment of the present invention.
  • a packet is received by driver 2 from protocol 3 (Step S2) .
  • Driver 2 according to the invention, examines each packet it receives on transmission from protocol 3 to determine special handling needed by the packet.
  • driver 1 looks for a protocol identifier in every packet it receives so as to determine which protocol created the packet (Step S4) . In one embodiment this is done by a subroutine within driver 2 referred to as the priority determining algorithm (PDA) 50.
  • PDA priority determining algorithm
  • Examples of possible packet protocols are PCP, EDP, UDP, or IPX.
  • PDA 50 Once PDA 50 has determined which protocol formatted a packet, PDA 50 then knows how and from where to read the header of the packet and to determine the source and destination socket numbers for the packet (Step S6) .
  • PDA 50 After determining the source socket number for a packet, PDA 50 determines what special handling instructions should be assigned to the packet. This is determined by PDA 50 reading from a configuration memory 52 the ranges of socket numbers that are assigned special handling instructions and determining in which range the socket number of the current packet falls (Step S8) .
  • driver 2 maintains at least two transmit queues of different priorities in computer system 10 such as high priority transmit queue 55 and low priority transmit queue 60. Based on the special handling determination made in Step S8 (Step S10) , driver 2 places the packet in one of these two transmit queues. In the current specific example, driver 2 will place a packet in either LPTXQ 60 (Step S12) or HPTXQ 55 (Step S16) , depending on the priority determination made for the packet. According to a further embodiment, driver 2 will add priority data to the packet header (Step S14) before the packet is placed in one of the two queues. This priority data may be added to either all high priority packets, all low priority packets, or all packets.
  • Figure 5 illustrates a further method of the invention whereby driver 2 also determines which packets will be sent to adapter 1 for transmission on network 15.
  • this determination is simple and is based on whether any packets are present in HPTXQ 55. If any packets are present HPTXQ 55, driver 2 sends those packets to adapter 1 immediately (Step T14) , and allows any packets within LPTXQ 60 to wait until there are no more HP packets in queue 55 remaining to be transmitted.
  • driver 2 ensures that at least some LP packets are transmitted even when there is a very high volume of HP packets being received by driver 2, referred to herein as fairness (Step T12) .
  • driver 2 maintains a count ITPC of HP packets transmitted without interruption, and when that count reaches a certain value, driver 2 sends out a packet from LPTXQ 60 to adapter 1 if one is present.
  • driver 2 is enabled to effectively schedule HP packets even when an adapter such as 1 includes a large transmit FIFO 110.
  • driver 2 takes responsibility of halting LP packets being transmitted to FIFO 110 when that FIFO becomes too full. Driver 2 does this to avoid the situation where FIFO 110 contains a large number of LP packets and driver 2 receives an HP priority packet to transmit.
  • driver 2 has no way to force the HP packet ahead of other packets stored in FIFO 110, and the HP packet would have to wait.
  • a driver 2 avoids this problem by maintaining an adapter FIFO transmit list 65, in which driver 2 logs the presence of all packets sent to adapter 110.
  • Driver 2 then examines the FIFO free space value returned from adapter 110 to determine which packets that it has stored have been sent by the adapter onto network 15.
  • driver 2 determines that a certain number of low priority packets reside on transmit FIFO 110 and have not been sent, driver 2 halts forwarding any further low priority packets to adapter 1 until the number of low priority packets stored in transmit FIFO 110 again falls below a certain threshold (Step T16) .
  • driver 2 first checks the packet traffic to determine if mixed HP and LP packets are being sent, before it halts transmission of packets to FIFO 110. If mixed traffic is not being sent, driver 2 suspends this technique and sends packets normally until transmit FIFO 110 is full.
  • FIG. 5 is a flow chart of the method by which an adapter including each of these alternative embodiments sends packets from its HPTXQ and LPTXQ to adapter 1.
  • Figure 6 illustrates a method of driver 2 for receiving packets according to a further embodiment of the invention.
  • a system such as 10 on a network
  • adapter 1 In a system such as 10 on a network, often several packets will be received in rapid succession by adapter 1 and will be present for service together in RX FIFO 115.
  • a driver 2 examines the header of each incoming packet when multiple packets are received, looking for a priority indication (Step U4). Because of the operation of RX FIFO 115, driver has no choice but to receive the packets out of FIFO 115 in FIFO order and cannot receive HP packets first. Driver 2 therefore stores any LP packet it receives in LPRXQ 70 (Step U10) and continues receiving packets from FIFO 115. When an HP packet is received, driver 2 immediately passes that packet up to protocol layer 3 (Step U8) . When all packets in FIFO 115 have been received by driver 2, driver 2 then passes any LP packets stored in LPRXQ 70 to protocol layer 3 (Step U8) . According to one embodiment, driver 2 first determines whether mixed priority packets are being received over network 15 (Step U6) before instituting storing packets in LPRXQ 70.
  • driver 2 may be embodied in computer executable code on a fixed computer medium, either for delivery to a computer 10 as a fixed disk or for delivery over a network. When loader on an appropriately configured computer, this code will cause the computer and associated hardware to perform in accordance with the methods of the invention. It should be understood that many of the above described individual features of the invention are configurable and may be enabled or disabled by configuration codes supplied to driver 2 by computer system 10.
  • An alternative embodiment of the invention includes just one TXQ, such as 55 and includes control circuitry allowing driver 2 to place packets at any location within queue 55 depending on the packets priority, which higher priority packets placed in the queue so that they will be transmitted first to adapter 1.
  • Fig. 7 illustrates an example of a computer system used to execute the software of the present invention.
  • Fig. 7 shows a computer system 10 which includes a monitor 703, screen 705, cabinet 707, keyboard 709, and mouse 711.
  • Mouse 111 may have one or more buttons such as mouse buttons 113.
  • Cabinet 107 is shown housing a disk drive 715 for reading a CD-ROM or other type disk 117.
  • Cabinet 707 also houses familiar computer components (not shown) such as a processor, memory, disk drives, and the like, as well as an adaptor 1 for connection to a network medium 15.
  • Fig. 8 shows a system block diagram of computer system 10 used to execute the software of the present invention.
  • computer system 10 includes monitor 703 and keyboard 709.
  • Computer system 10 further includes subsystems such as a central processor 722, system memory 724, I/O controller 726, display adapter 728, serial port 732, disk 736, network interface 738, adaptor 1 and speaker 740.
  • Computer readable media such as memory, hard disks, floppies, CD-ROMs, tapes, flash memory, and the like may be used to store a computer program including computer code that implements the present invention.
  • Other computer systems suitable for use with the present invention may include additional or fewer subsystems.
  • another computer system could include more than one processor 722 (i.e., a multi-processor system) or a system may include a cache memory.
  • Arrows such as 722 represent the system bus architecture of computer system 10. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems.
  • speaker 740 could be connected to the other subsystems through a port or have an internal direct connection to central processor 722.
  • Computer system 10 shown in Fig. 8 is but an example of a computer system suitable for use with the present invention. Other configurations of subsystems suitable for use with the present invention will be readily apparent to one of ordinary skill in the art.

Abstract

A network adaptor driver includes an algorithm for determining special handling of packets by examining socket or port indications for the packets and a means for setting a special handling field in the header of outgoing packets. Specific embodiments include a table for connections that include packets without socket indications, a transmit FIFO list for determining whether a transmit FIFO is full, and a low priority receive queue. A computer readable media allowing a computer to practice the method of the invention is disclosed.

Description

PACKET FILTERING BASED ON SOCKET OR APPLICATION IDENTIFICATION
APPENDIX
This application is being filed with a paper appendix consisting of 95 pages containing a source code listing for an embodiment of the invention. A microfiche reproduction of this appendix will be submitted upon notice of allowance.
BACKGROUND OF THE INVENTION
This application is a Continuation-In-Part of co- assigned pending U.S. Application Serial No. 08/313,674, entitled METHOD AND APPARATUS FOR CONTROLLING LATENCY AND JITTER IN A LOCAL AREA NETWORK WHICH USES A CSMA/CD PROTOCOL.
The current invention relates to the field of electronic circuits. More particularly, the current invention relates to transmission of information between digital devices over a communications medium.
The present invention relates to the field of data communication over a computer network. A very wide variety of types of computer networks exist, each having many variations in particular implementations. The present invention will be described with reference to a particular types of computer networks, operating systems, and network interfaces. This should not be taken to limit the invention, and it will be apparent to those of skill in the art that the invention has applications in many different types of computer networks.
The invention therefore should not be seen as limited except as provided in the attached claims.
Digital computer networks have become ubiquitous in academic, industry, and office environments. A number of different aspects of computer networks are discussed in co- assigned pending U.S. applications serial nos. 08/313,674; 08/542,157; 08/506,533; and 08/329,714 each of which are incorporated herein by reference. Most of the commonly used networks today operate in accordance with a layered protocol sui te. In a layered protocol suite, various network tasks are divided among different pieces of hardware and software in order to allow maximum flexibility and reliability between software units. Fig. 1 shows a simplified block diagram of a layered protocol suite as might exist between a personal computer 10 and a server computer 20 communicating via a network 15, such as two Windows-compatible type computers in an office environment running over a LAN. In a simplified form, such a system can be thought of as comprising four semi-independent layers running on each computer.
A top layer, layer 4, is the application layer. The application layer generally is occupied by software running on the central processor of computer 10. This software might include video conferencing software, e-mail software, the file system, or any other software that accesses network 15. The application layer 4 on computer 10 communicates data, such as a video conferencing signal, with an application layer on computer 20, by passing that data down through the protocol stack on computer 10 to the lowest layer, layer 1. Layer 1 provides a physical connection to the network and sends the data to the layer 1 device on computer 20, which then passes the data back up to its application layer.
Application layer 4 communicates data down to protocol layer 3. Protocol layer 3 includes software necessary to perform high level network functions such as accepting a data file from an application layer, dividing that file into packets, and attaching to those packets source and destination address information so that packets can be effectively transmitted over the network. Some examples of different protocol layer software are TCP/IP or IPX. The protocol layer communicates with an adapter driver layer 2 . Layer 2 generally includes software for interfacing between adapter 1 and the protocol layer 3. In prior art layered implementations, layer 2 is generally low level software whose primary purpose is to act as the interface between the protocol layer and the particular adapter hardware that is connected to or a part of computer system 10. In prior art networks, layer 2 software does not examine the contents or address of any data passing through it, but merely formats that data for the particular adapter to place on the network. Some examples of driver layer software are NDIS2 or ODl.
Adapter 1 is generally thought of as a piece of hardware for communicating signals over the network media. Adapter 1 will have different configurations depending on whether the network media is a co-axial cable, twisted-pair wire, fiber optic cable, or radio waves. The adapter may be a plug in board that connects to computer 10's system bus. Once adapter 1 receives a packet of data to be transmitted over network 15, it sends a packet over network 15 which delivers it to an adapter IA in addressed computer 20. Once data reaches address computer 20, adapter IA passes the packet up the layered stack first to driver layer 2A, then to protocol layer 3A, which then passes to application layer 4A. An adapter generally includes circuitry and connectors for communication over a network medium and translates data from the digital form used by the computer circuitry a form that may be transmitted over a medium, such as a waveform. A driver is a set of instructions resident on a device that allows the device to accomplish various tasks as defined by different network protocols. Drivers are generally software programs stored on the computer in a manner that allows the drivers to be modified without modifying other hardware. In a layered network system such as shown in Fig. 1, various networking tasks are tightly defined and performed at various network layers. In prior art systems, driver 2, for example, receives packets of data and forwards them immediately to adapter 1 without examining the contents of the packets of data and without ever changing any of the contents of the packets of data. Driver 2 essentially exists to be an interface between a wide variety of different hardware equipment that may be provided as adapter 1 and the limited number of different network protocols 3 that might be supported by computer system 10. In prior art systems, driver 1 simply sends each packet as it receives it or sends packets in a strict FIFO order where the first packet received from protocol 3 is the first packet sent out to adapter 1 and over the network.
The layered system shown in Fig. 1 has worked well in network environments where a majority of network traffic consists of text or computer instructions which do not have particular time-critical requirements and where a computer, such as 10, only allowed one application to access the network at a time.
However, two developments in personal computer technology have shown that this system has certain limitations. The first is the wide-spread use of socket capable protocols and operating systems in networked environments. In a socket system, multiple applications running simultaneously on computer 10 can simultaneously send and receive data on network 15. Protocol layer 3 keeps track of for which application a particular data packet is destined by assigning different socket numbers. Socket numbers are requested by applications from protocol layer 3. All data packets sent and received include this number in their headers and thus can be delivered to the right application. The location of the socket identification within the packet is determined by the packet's network protocol.
The second development that has highlighted the limitations of prior art adapter drivers is that computer network traffic has increasingly begun to include real-time data such as digitized audio signals and digitized video signals, such as signals that might be used for a real time video conferencing system. In a sockets compatible computer system, this real-time network data might be attempting to use the network at the same time that other, high volume but non- time critical, computer data is being placed on the network by a different application. Without a way for the computer system to ensure that real time video and audio data is delivered at a high priority while delays are allowed to happen in data streams that are not time critical, the real¬ time data can be delayed unacceptably long, hurting multi- media performance.
What is needed is a method and apparatus allowing a computer system such as 10 to send real-time data on a network at a higher priority than non-time-critical data and that requires minimal modification to other network hardware or software.
SUMMARY OF THE INVENTION
The present invention is an adapter driver for use with a network adapter card designed to recognize an identification field from an application layer program and to assign special handling or fil tering to packets received from said application program based on the identification code. In a specific case, this filtering includes assigning a priority to individual packets. According to a specific embodiment, a driver assigns one of two priorities: a high priority (HP) or a low priority (LP) . With the assignment of priority, a driver according to the present invention can manage and determine in what order packets are passed to an adapter 1 such that high priority packets are transmitted on the network before low priority packets are transmitted on the network. According to a further embodiment of the invention, a driver according to the invention may also change data in a packet's header, thereby identifying special handling indications of said packet to other communications devices in a network. According to a further embodiment of the invention, a driver according to the invention may detect a high priority bit in a received packet's header and thereby deliver that packet to the layer 3 protocol ahead of other received packets.
According to a specific embodiment, a driver is designed to operate in a computer system which can function with a number of different network protocols. The driver includes instructions allowing it to read a network protocol identifier from a packet of data and then to determine the source and destination address from said packet based on the protocol used to encode said packet. An example of one type of system in which the invention may be used is the Windows(TM) operating system, developed and sold by Microsoft(TM) Corporation. In the Windows operating system, applications communicating data to a network identify packets of data with a socket identification. The location of this socket identification within the packet is determined by the packet's network protocol. (In other operating systems, the name for what Window's calls a socket is a port . )
In a Windows embodiment, a driver according to the invention reads a packet protocol and from the packet protocol determines the location of a socket identifier. The driver then reads the socket identifier and from it determines the priority of a packet. According to a specific embodiment, packet priority may be based on assigning particular ranges of socket identifiers to particular priorities. Such assignments may be stored in a configuration file on a computer such as computer 10 to be read by the adapter driver at startup.
A further example of an environment in which the invention may be employed is the Apple operating system. In the Apple operating system, ar-" ications also assign an identifier to every packet o.. α~ta that is sent to the protocol layer.
An adapter driver according to one embodiment of the invention may include one or more priority transmit queues. These queues, according to one embodiment, are established by the driver in computer 10's main system memory. According to a different embodiment, these queues may be placed in a dedicated memory on the adapter card. According to still another embodiment, a driver may handle high priority packets by interacting directly with memory on the adaptor card and without using priority queues. Where a driver interacts with just one priority queue, the driver includes control means allowing it to place packets at any location in the queues depending on the packet's priority. Where a driver interacts with multiple queues, a packet is located within a queue indicating that packet's priority.
According to one embodiment of the invention, an adapter driver according to the invention may be implemented entirely in software and may be designed to run on existing computer systems with existing higher layer protocol drivers and existing adapters. In this way, the advantages of the invention may be achieved by modifying only the adapter driver software on a computer such as 10, which is a relatively inexpensive investment to gain the performance benefits of the invention. This software may be embodied in computer readable executable instructions written onto a fixed medium such as a disk, for distribution to individual computer systems either via removeable or fixed disks or over a transmission medium.
In a different embodiment, the invention may be used in conjunction with other modified network software and hardware to achieve further enhancements in performance.
These other modified network elements could include network switching devices that recognize a priority field set by an adapter driver according to the invention and that provide special handling for high priority packets. In a further embodiment, a driver according to the invention is optimized to run on a modified adapter card which is designed to recognize and provide special handling for high priority packets.
Finally, the essential technique of the invention includes using an adaptor driver to examine higher layer information in a packet in order to mark the packet for various special handling. In addition to priority handling, this special handling could include encryption, compression, or security blocking. This special handling is distinct from prior art handling of network data because it is done on a packet by packet basis by the adaptor driver layer of the protocol. The present invention is intended to encompass these variations.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a diagram illustrating a layered network protocol of a type in which the present invention may be effectively employed.
Fig. 2 is a block diagram of a computer system and an adapter with a driver according to an embodiment of the present invention. Fig. 3 is a diagram of an example of a packet format which may be effectively handled by the present invention.
Fig. 4 is a flow chart of a method of the driver for special handling of the packets according to the present invention. Fig. 5 is a flow chart of a method by which a driver according to the present invention sends packets to an adapter.
Fig. 6 is a flow chart of a method by which a driver according to the present invention receives and buffers low priority packets.
Fig. 7 is a block diagram of a computer system with an ability to read a computer readable medium allowing the system to operate in accordance with the invention.
Fig. 8 shows a system block diagram of computer system 10 used to execute the software of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Fig. 2 illustrates a computer system 10 containing an adapter 1, an adapter driver 2 according to an embodiment the invention, a protocol layer 3, and application layer 4. Driver 2 has associated with it a protocol detection algorithm (PDA) 50, a high priority transmit queue (HPTXQ) 55, and a low priority transmit queue (LPTXQ) 60. According to one embodiment, driver 2 also has associated with it an adapter FIFO transmit list 65 and a low priority receive queue (LPRXQ) 70.
Adapter 1 has associated with it an adapter transmit FIFO 110 and an adapter receive FIFO 115. Adapter 1 communicates packets through driver 2 to computer system 10 and transmits and receives packets from network 15.
Fig. 3 illustrates an example of a network protocol packet which may be effectively handled by an adapter driver according to the present invention. Fig. 3 illustrates a packet 200, containing packet header 202. Packet header 202 contains, a protocol identifier 210, a source socket identifier 204, a source address 206, a destination socket identifier 208, and a destination address 210. According to the present invention, packet header 202 may also contain a locally administered bit 212 which is used by an embodiment of the present invention to indicate special handling of the packet in the network 15.
The present invention according to one embodiment may also determine the sockets of packets where not every packet includes a socket identification, such as UDP protocol packets. In the case, a driver 2 according to the invention, maintains a table of UDP identifiers along with the socket to which a particular UDP connection is assigned. Fig. 4 illustrates a flow chart of the operation of adapter driver 2 illustrating the method of the special handling of packets based on their source socket or their destination socket address according to an embodiment of the present invention. A packet is received by driver 2 from protocol 3 (Step S2) . Driver 2, according to the invention, examines each packet it receives on transmission from protocol 3 to determine special handling needed by the packet. First, driver 1 looks for a protocol identifier in every packet it receives so as to determine which protocol created the packet (Step S4) . In one embodiment this is done by a subroutine within driver 2 referred to as the priority determining algorithm (PDA) 50. Examples of possible packet protocols are PCP, EDP, UDP, or IPX.
Once PDA 50 has determined which protocol formatted a packet, PDA 50 then knows how and from where to read the header of the packet and to determine the source and destination socket numbers for the packet (Step S6) .
After determining the source socket number for a packet, PDA 50 determines what special handling instructions should be assigned to the packet. This is determined by PDA 50 reading from a configuration memory 52 the ranges of socket numbers that are assigned special handling instructions and determining in which range the socket number of the current packet falls (Step S8) .
According to an embodiment of the current invention, driver 2 maintains at least two transmit queues of different priorities in computer system 10 such as high priority transmit queue 55 and low priority transmit queue 60. Based on the special handling determination made in Step S8 (Step S10) , driver 2 places the packet in one of these two transmit queues. In the current specific example, driver 2 will place a packet in either LPTXQ 60 (Step S12) or HPTXQ 55 (Step S16) , depending on the priority determination made for the packet. According to a further embodiment, driver 2 will add priority data to the packet header (Step S14) before the packet is placed in one of the two queues. This priority data may be added to either all high priority packets, all low priority packets, or all packets.
Figure 5 illustrates a further method of the invention whereby driver 2 also determines which packets will be sent to adapter 1 for transmission on network 15.
According to one example, this determination is simple and is based on whether any packets are present in HPTXQ 55. If any packets are present HPTXQ 55, driver 2 sends those packets to adapter 1 immediately (Step T14) , and allows any packets within LPTXQ 60 to wait until there are no more HP packets in queue 55 remaining to be transmitted.
According to a related further embodiment of the invention, driver 2 ensures that at least some LP packets are transmitted even when there is a very high volume of HP packets being received by driver 2, referred to herein as fairness (Step T12) . In this embodiment, driver 2 maintains a count ITPC of HP packets transmitted without interruption, and when that count reaches a certain value, driver 2 sends out a packet from LPTXQ 60 to adapter 1 if one is present.
According to a further embodiment of the invention, driver 2 is enabled to effectively schedule HP packets even when an adapter such as 1 includes a large transmit FIFO 110. In order to operate effectively with prior art adapters 1, which are not aware of the scheduling of HP and LP packets, driver 2 takes responsibility of halting LP packets being transmitted to FIFO 110 when that FIFO becomes too full. Driver 2 does this to avoid the situation where FIFO 110 contains a large number of LP packets and driver 2 receives an HP priority packet to transmit. When used with prior art adapters, driver 2 has no way to force the HP packet ahead of other packets stored in FIFO 110, and the HP packet would have to wait.
A driver 2 according to this embodiment of the invention, avoids this problem by maintaining an adapter FIFO transmit list 65, in which driver 2 logs the presence of all packets sent to adapter 110. Driver 2 then examines the FIFO free space value returned from adapter 110 to determine which packets that it has stored have been sent by the adapter onto network 15. When driver 2 determines that a certain number of low priority packets reside on transmit FIFO 110 and have not been sent, driver 2 halts forwarding any further low priority packets to adapter 1 until the number of low priority packets stored in transmit FIFO 110 again falls below a certain threshold (Step T16) .
In a further embodiment of the invention, driver 2 first checks the packet traffic to determine if mixed HP and LP packets are being sent, before it halts transmission of packets to FIFO 110. If mixed traffic is not being sent, driver 2 suspends this technique and sends packets normally until transmit FIFO 110 is full.
Figure 5 is a flow chart of the method by which an adapter including each of these alternative embodiments sends packets from its HPTXQ and LPTXQ to adapter 1.
Figure 6 illustrates a method of driver 2 for receiving packets according to a further embodiment of the invention. In a system such as 10 on a network, often several packets will be received in rapid succession by adapter 1 and will be present for service together in RX FIFO 115.
According to this embodiment, a driver 2 examines the header of each incoming packet when multiple packets are received, looking for a priority indication (Step U4). Because of the operation of RX FIFO 115, driver has no choice but to receive the packets out of FIFO 115 in FIFO order and cannot receive HP packets first. Driver 2 therefore stores any LP packet it receives in LPRXQ 70 (Step U10) and continues receiving packets from FIFO 115. When an HP packet is received, driver 2 immediately passes that packet up to protocol layer 3 (Step U8) . When all packets in FIFO 115 have been received by driver 2, driver 2 then passes any LP packets stored in LPRXQ 70 to protocol layer 3 (Step U8) . According to one embodiment, driver 2 first determines whether mixed priority packets are being received over network 15 (Step U6) before instituting storing packets in LPRXQ 70.
According to one embodiment of the invention, driver 2 may be embodied in computer executable code on a fixed computer medium, either for delivery to a computer 10 as a fixed disk or for delivery over a network. When loader on an appropriately configured computer, this code will cause the computer and associated hardware to perform in accordance with the methods of the invention. It should be understood that many of the above described individual features of the invention are configurable and may be enabled or disabled by configuration codes supplied to driver 2 by computer system 10.
An alternative embodiment of the invention includes just one TXQ, such as 55 and includes control circuitry allowing driver 2 to place packets at any location within queue 55 depending on the packets priority, which higher priority packets placed in the queue so that they will be transmitted first to adapter 1.
Fig. 7 illustrates an example of a computer system used to execute the software of the present invention. Fig. 7 shows a computer system 10 which includes a monitor 703, screen 705, cabinet 707, keyboard 709, and mouse 711. Mouse 111 may have one or more buttons such as mouse buttons 113. Cabinet 107 is shown housing a disk drive 715 for reading a CD-ROM or other type disk 117. Cabinet 707 also houses familiar computer components (not shown) such as a processor, memory, disk drives, and the like, as well as an adaptor 1 for connection to a network medium 15.
Fig. 8 shows a system block diagram of computer system 10 used to execute the software of the present invention. As in Fig. 7, computer system 10 includes monitor 703 and keyboard 709. Computer system 10 further includes subsystems such as a central processor 722, system memory 724, I/O controller 726, display adapter 728, serial port 732, disk 736, network interface 738, adaptor 1 and speaker 740. Computer readable media such as memory, hard disks, floppies, CD-ROMs, tapes, flash memory, and the like may be used to store a computer program including computer code that implements the present invention. Other computer systems suitable for use with the present invention may include additional or fewer subsystems. For example, another computer system could include more than one processor 722 (i.e., a multi-processor system) or a system may include a cache memory. Arrows such as 722 represent the system bus architecture of computer system 10. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems. For example, speaker 740 could be connected to the other subsystems through a port or have an internal direct connection to central processor 722. Computer system 10 shown in Fig. 8 is but an example of a computer system suitable for use with the present invention. Other configurations of subsystems suitable for use with the present invention will be readily apparent to one of ordinary skill in the art.
The invention has now been explained with reference to specific embodiments. Other embodiments will be apparent to those of skill in the art. In particular, method steps have been grouped and labeled as being part of various sub-methods in order to increase clarity of the disclosure, however, these steps could be differently grouped without changing the essential operation of the invention. It is therefore not intended that this invention be limited, except as indicated by the appended claims.

Claims

WHAT IS CLAIMED IS; 1. A network adapter driver comprising: an interface for transmitting formatted packets of data to and from a higher protocol layer; a special handling detection algorithm for reading the protocol identifier from a packet of data, for reading a socket identifier from said packet of data, and for determining a special handling indication for said packet based on said socket identifier; and a transmit interface for transmitting packets of data to a network adapter with special handling based on the special handling indication of said packets.
2. A network adapter driver according to claim 1 further comprising: configuration memory for storing special handling indications based on ranges of source socket identifiers of said packets.
3. A network adapter driver according to claim 1 further comprising: a packet header modification algorithm for modifying a data field in a packet header in order to indicate a special handling indication of said packet.
4. A network adapter driver according to claim 1 further comprising: a table for storing socket indications for protocols that include packets that do not have socket indications in each packet header.
5. A network adapter driver according to claim 1 wherein said adapter driver is a software module that may be installed on a computer system with an adapter without any modifications to said computer system or said adapter.
6. A method for providing special handling of packets in an adapter driver comprising the steps of: receiving a packet of data from a higher protocol layer, said packet containing a packet header; reading from said packet header and indication of the protocol that constructed that packet; using said protocol to determine where in said header a source or a destination socket identifier is located and reading said socket identifier(s) ; using said identifier(s) to determine special handling for said packet; and transmitting said packet to an adaptor in accordance with said special handling.
7. The method according to claim 6 further comprising: adding data to said packet header indicating said special handling before transferring said packets to an adaptor.
8. A fixed computer readable medium containing computer executable program code that when loaded into an appropriately configured computer system will cause the computer to perform the method of claim 6.
9. A fixed computer readable medium containing computer executable program code that when loaded into an appropriately configured computer system will cause the computer to perform the method of claim 7.
10. A network adapter driver comprising: an interface for transmitting formatted packets of data to and from a higher protocol layer; a priority detection algorithm for reading the protocol identifier from a packet of data, for reading a socket identifier from said packet of data, and for determining a priority indication for said packet based on said socket identifier; and a transmit interface for transmitting packets of data to a network adapter with special handling based on the priority indication of said packets.
11. A network adapter driver according to claim 10 further comprising: a priority transmit queue interface for storing packets to be transmitted into locations into a plurality of transmit queues based on a priority indication of said packets.
12. A network adapter driver according to claim 10 further comprising a receive queue interface for temporarily storing received packets that have a low priority indication.
13. A network adapter driver according to claim 10 further comprising: a transmit FIFO control interface for receiving signals indicating the amount of free space in an adapter transmit FIFO; and a transmit FIFO list memory for storing indications of which packets in a transmit FIFO have been sent wherein said adapter driver halts placing additional low priority packets in said transmit FIFO when a specified number of packets are determined to be residing is said transmit FIFO.
14. A network adapter driver according to claim 10 further comprising: configuration memory for storing priority indications based on ranges of source socket identifiers of said packets.
15. A network adapter driver according to claim 10 further comprising: a packet header modification algorithm for modifying a data field in a packet header in order to indicate a priority of said packet.
16. A network adapter driver according to claim 10 further comprising: a table for storing socket indications for protocols that include packets that do not have socket indications in each packet header.
17. A network adapter driver according to claim 10 further comprising a first transmit queue interface for a high priority transmit queue and a said second transmit queue interface for a low priority transmit queue.
18. A network adapter driver according to claim 10 wherein said adapter driver is a software module that may be installed on a computer system with an adapter without any modifications to said computer system or said adapter and wherein said queues are allocated by said driver from said computer system's system memory.
19. A method for scheduling transmission of packets in an adapter driver comprising the steps of: receiving a packet of data from a higher protocol layer said packet containing a packet header; reading from said packet header and indication of the protocol that constructed that packet; using said protocol to determine where in said header a source socket identifier is located and reading said socket identifier; using said identifier to determine a priority for said packet; and placing said packet into a transmit queue in a location indicated by said priority.
20. The method according to claim 19 further comprising: sending packets out of said higher priority queue locations before sending them out of lower priority locations.
21. The method according to claim 19 further comprising: adding data to said packet header indicating said priority before placing said packets a queue.
22. The method according to claim 19 further comprising: adding data to said packet header indicating said priority before placing said packets a queue.
23. A fixed computer readeable medium containing computer executable program, which, when loaded into an appropriately configured computer system will cause the computer to perform the method of claim 19.
PCT/US1997/007271 1996-04-30 1997-04-29 Packet filtering based on socket or application identification WO1997041674A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU28206/97A AU2820697A (en) 1996-04-30 1997-04-29 Packet filtering based on socket or application identification

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US64139996A 1996-04-30 1996-04-30
US08/641,399 1996-04-30

Publications (2)

Publication Number Publication Date
WO1997041674A2 true WO1997041674A2 (en) 1997-11-06
WO1997041674A3 WO1997041674A3 (en) 1998-02-05

Family

ID=24572211

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/007271 WO1997041674A2 (en) 1996-04-30 1997-04-29 Packet filtering based on socket or application identification

Country Status (2)

Country Link
AU (1) AU2820697A (en)
WO (1) WO1997041674A2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999059303A2 (en) * 1998-05-14 1999-11-18 Telia Ab (Publ) A communications network or an ip-network which incorporates a packet classifier
WO2000048373A1 (en) * 1999-02-10 2000-08-17 Nokia Mobile Phones Ltd. Method for informing layers of a protocol stack about the protocol in use
WO2000056023A1 (en) * 1999-03-12 2000-09-21 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for policing and forwarding data in a data communications system
WO2001005120A1 (en) * 1999-07-08 2001-01-18 Telefonaktiebolaget Lm Ericsson (Publ) Internet protocol stack for real-time applications
WO2002025889A2 (en) * 2000-09-19 2002-03-28 Nice Systems Ltd. Communication management system for computer network based telephones
WO2002069595A2 (en) * 2001-02-27 2002-09-06 Mayah Communications Gmbh Method for recognizing audio-visual data in transmission networks, in particular internet
EP1406424A2 (en) * 2002-10-01 2004-04-07 NEC Infrontia Corporation Terminal device, method for processing communication data inside the terminal device, and program for implementing the method
US6865604B2 (en) 1998-08-26 2005-03-08 Sts Software Systems Ltd. Method for extracting a computer network-based telephone session performed through a computer network
DE102009021908B4 (en) * 2009-05-19 2011-06-22 Kress, Wolfram, 53721 Method for transmitting data
CN101222443B (en) * 2008-01-30 2012-04-25 杭州华三通信技术有限公司 Method and network appliance for processing packet

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0272834A2 (en) * 1986-12-22 1988-06-29 AT&T Corp. Inter-processor communication protocol
WO1994001828A1 (en) * 1992-07-02 1994-01-20 Wellfleet Communications Data packet processing method and apparatus
EP0669742A2 (en) * 1994-01-26 1995-08-30 Hughes Aircraft Company Multimedia frame relay codec
US5481735A (en) * 1992-12-28 1996-01-02 Apple Computer, Inc. Method for modifying packets that meet a particular criteria as the packets pass between two layers in a network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0272834A2 (en) * 1986-12-22 1988-06-29 AT&T Corp. Inter-processor communication protocol
WO1994001828A1 (en) * 1992-07-02 1994-01-20 Wellfleet Communications Data packet processing method and apparatus
US5481735A (en) * 1992-12-28 1996-01-02 Apple Computer, Inc. Method for modifying packets that meet a particular criteria as the packets pass between two layers in a network
EP0669742A2 (en) * 1994-01-26 1995-08-30 Hughes Aircraft Company Multimedia frame relay codec

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
D.COFFIELD ET AL: "TUTORIAL GUIDE TO UNIX SOCKETS FOR NETWORK COMMUNICATIONS" COMPUTER COMMUNICATIONS., vol. 10, no. 1, February 1987, GUILDFORD GB, pages 21-29, XP000577221 *

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999059303A3 (en) * 1998-05-14 2000-03-09 Telia Ab A communications network or an ip-network which incorporates a packet classifier
WO1999059303A2 (en) * 1998-05-14 1999-11-18 Telia Ab (Publ) A communications network or an ip-network which incorporates a packet classifier
US6871229B2 (en) 1998-08-26 2005-03-22 Sts Software Systems Ltd. Method for storing on a computer network a portion of a communication session between a packet source and a packet destination
US7581001B2 (en) 1998-08-26 2009-08-25 Sts Systems Ltd. Communication management system for computer network-based telephones
US6880004B2 (en) 1998-08-26 2005-04-12 Sts Software Systems Ltd. Method for restoring a portion of a communication session transmitted over a computer network
US6865604B2 (en) 1998-08-26 2005-03-08 Sts Software Systems Ltd. Method for extracting a computer network-based telephone session performed through a computer network
WO2000048373A1 (en) * 1999-02-10 2000-08-17 Nokia Mobile Phones Ltd. Method for informing layers of a protocol stack about the protocol in use
US7505444B2 (en) 1999-02-10 2009-03-17 Nokia Corporation Method for informing layers of a protocol stack about the protocol in use
US6990107B1 (en) 1999-02-10 2006-01-24 Nokia Mobile Phones, Ltd. Method for informing layers of a protocol stack about the protocol in use
WO2000056023A1 (en) * 1999-03-12 2000-09-21 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for policing and forwarding data in a data communications system
WO2001005120A1 (en) * 1999-07-08 2001-01-18 Telefonaktiebolaget Lm Ericsson (Publ) Internet protocol stack for real-time applications
US6707791B1 (en) 1999-07-08 2004-03-16 Telefonaktiebolaget Lm Ericsson (Publ) Internet protocol stack for real time applications
WO2002025889A3 (en) * 2000-09-19 2002-08-15 Nice Systems Ltd Communication management system for computer network based telephones
EP1635535A3 (en) * 2000-09-19 2006-06-07 Nice Systems Ltd. Communication management system for recording communications sessions
AU781291B2 (en) * 2000-09-19 2005-05-12 Nice Systems Ltd. Communication management system for computer network based telephones
WO2002025889A2 (en) * 2000-09-19 2002-03-28 Nice Systems Ltd. Communication management system for computer network based telephones
EP1635534A3 (en) * 2000-09-19 2006-06-07 Nice Systems Ltd. Communication management system for recording at least a portion of a communication session
EP1635535A2 (en) * 2000-09-19 2006-03-15 Nice Systems Ltd. Communication management system for recording communications sessions
EP1635534A2 (en) * 2000-09-19 2006-03-15 Nice Systems Ltd. Communication management system for recording at least a portion of a communication session
WO2002069595A2 (en) * 2001-02-27 2002-09-06 Mayah Communications Gmbh Method for recognizing audio-visual data in transmission networks, in particular internet
WO2002069595A3 (en) * 2001-02-27 2002-11-28 Mayah Comm Gmbh Method for recognizing audio-visual data in transmission networks, in particular internet
EP1406424A3 (en) * 2002-10-01 2006-03-08 NEC Infrontia Corporation Terminal device, method for processing communication data inside the terminal device, and program for implementing the method
US7356034B2 (en) 2002-10-01 2008-04-08 Nec Infrontia Corporation Terminal device, method for processing communication data inside the terminal device, and program for implementing the method
EP1406424A2 (en) * 2002-10-01 2004-04-07 NEC Infrontia Corporation Terminal device, method for processing communication data inside the terminal device, and program for implementing the method
CN101222443B (en) * 2008-01-30 2012-04-25 杭州华三通信技术有限公司 Method and network appliance for processing packet
DE102009021908B4 (en) * 2009-05-19 2011-06-22 Kress, Wolfram, 53721 Method for transmitting data

Also Published As

Publication number Publication date
AU2820697A (en) 1997-11-19
WO1997041674A3 (en) 1998-02-05

Similar Documents

Publication Publication Date Title
US7136355B2 (en) Transmission components for processing VLAN tag and priority packets supported by using single chip's buffer structure
Shanley InfiniBand network architecture
US5996024A (en) Method and apparatus for a SCSI applications server which extracts SCSI commands and data from message and encapsulates SCSI responses to provide transparent operation
US6651119B2 (en) Method for allocating priorities to plurality of DMA engines for processing data packets based on bus phase and transactions status
US5742607A (en) Method and apparatus for controlling two way communication via disparate physical media
US6957269B2 (en) Method and apparatus for performing priority-based flow control
US6016513A (en) Method of preventing packet loss during transfers of data packets between a network interface card and an operating system of a computer
US6874147B1 (en) Apparatus and method for networking driver protocol enhancement
US7200641B1 (en) Method and system for encoding SCSI requests for transmission using TCP/IP
US6327637B1 (en) Interface tap for 1394-enabled serial bus device
JP2002503914A (en) Method and apparatus for establishing a dynamic ESCON connection from a Fiber Channel frame
CA2348253A1 (en) Data storage system
WO1997041674A2 (en) Packet filtering based on socket or application identification
US20040019895A1 (en) Dynamic communication tuning apparatus, systems, and methods
US7054962B2 (en) Embedded system having broadcast data storing controller
EP1323273B1 (en) Network Transmitter using transmission priorities and corresponding method
US6578096B1 (en) Method and system for efficient I/O operation completion in a fibre channel node
US6990535B1 (en) Device and method for multi-ported, single bus-mastering data buffer management
CN1266912C (en) Multiple buffers for removing unwanted header information from received data packets
US20050102431A1 (en) Composite adapter for multiple peripheral functionality in portable computing system environments
EP0470875B1 (en) Communication controller between a computer and a plurality of ISDN terminals
US6954427B1 (en) Method and apparatus for performing priority-based admission control
US20020129099A1 (en) Method and apparatus for virtualizing a serial port in a data processing system
US5819113A (en) Method of identifying end of pocket by writing the address of last data into the first location of the memory
US6092125A (en) Method and apparatus for transferring data from devices not supporting burst data transfers in burst mode

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AU CA GB JP

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AU CA GB JP

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97539196

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA