US20080279208A1 - System and method for buffering data received from a network - Google Patents
System and method for buffering data received from a network Download PDFInfo
- Publication number
- US20080279208A1 US20080279208A1 US12/176,971 US17697108A US2008279208A1 US 20080279208 A1 US20080279208 A1 US 20080279208A1 US 17697108 A US17697108 A US 17697108A US 2008279208 A1 US2008279208 A1 US 2008279208A1
- Authority
- US
- United States
- Prior art keywords
- packet
- buffer
- entry
- logic
- sequence
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F5/00—Methods or arrangements for data conversion without changing the order or content of the data handled
- G06F5/06—Methods or arrangements for data conversion without changing the order or content of the data handled for changing the speed of data flow, i.e. speed regularising or timing, e.g. delay lines, FIFO buffers; over- or underrun control therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/901—Buffering arrangements using storage descriptor, e.g. read or write pointers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9021—Plurality of buffers per packet
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2205/00—Indexing scheme relating to group G06F5/00; Methods or arrangements for data conversion without changing the order or content of the data handled
- G06F2205/06—Indexing scheme relating to groups G06F5/06 - G06F5/16
- G06F2205/064—Linked list, i.e. structure using pointers, e.g. allowing non-contiguous address segments in one logical buffer or dynamic buffer space allocation
Definitions
- large amounts of data are transmitted from a transmitting unit through a network to at least one receiving unit.
- a graphics application at a transmitting unit may transmit graphical data to at least one remote receiving unit that renders the graphical data to form a rendered image.
- communication of large amounts of graphical data at a relatively high transmission rate may be needed in order to provide a suitable frame rate for the rendered image.
- Performance of a system's transmitting and receiving units in transmitting data to and receiving data from a network is typically an important factor in whether graphical data can be successfully rendered via a remote receiving unit at suitable frame rates.
- achieving a suitable transmission rate for the data communicated from the transmitting unit to the receiving unit or units can sometimes be problematic, particularly in instances where a large number of receiving units are to receive the graphical data.
- the transmitting unit may be configured to transmit each graphics command multiple times through the network (e.g., once for each destination receiving unit that is to receive the command).
- the multiple transmissions of the graphics commands can significantly increase the amount of data that is to be communicated through the network.
- embodiments of the present invention provide a system and method for buffering data received from a network.
- An exemplary system in accordance with one embodiment of the present invention comprises a network socket and receive logic.
- the receive logic is configured to perform a bulk read of the network socket and to store data from the bulk read into one of a plurality of buffers.
- the receive logic is further configured to perform a scan of the one buffer and to detect, based on the scan, a partial packet stored in the one buffer.
- the receive logic is further configured to write the partial packet to a second one of the buffers in response to a detection of the partial packet.
- Another exemplary system in accordance with another embodiment of the present invention comprises a network socket, a plurality of buffers, a buffer pointer pool, receive logic, and packet delivery logic.
- the buffer pointer pool has a plurality of entries respectively pointing to the buffers.
- the receive logic is configured to pull an entry from the pool and to perform a bulk read of the network socket.
- the entry points to one of the buffers, and the receive logic is further configured to store data from the bulk read to the one buffer based on the entry.
- the packet delivery logic is configured to read, based on the entry, the one buffer and to locate a missing packet sequence in response to a determination, by the packet delivery logic, that the one buffer is storing an incomplete packet sequence.
- the packet delivery logic is further configured to form a complete packet sequence based on the incomplete packet sequence and the missing packet sequence.
- FIG. 1 is a block diagram illustrating an exemplary communication system in accordance with the present invention.
- FIG. 2 is a block diagram illustrating an exemplary transmitting unit, such as is depicted in FIG. 1 .
- FIG. 3 is a block diagram illustrating an exemplary data packet that may be transmitted from a transmitting unit, such as is depicted in FIG. 2 .
- FIG. 4 is a block diagram illustrating an exemplary buffering system, such as is depicted in FIG. 1 .
- FIG. 5 is a block diagram illustrating an exemplary buffer pointer entry, such as is depicted in FIG. 4 .
- FIG. 6 is a block diagram illustrating an exemplary rendering element, such as is depicted in FIG. 4 .
- FIG. 7 is block diagram illustrating an exemplary computer system that may be used to implement a buffering system, such as is depicted in FIG. 4 .
- FIG. 8 is a flow chart illustrating an exemplary architecture and functionality of receive logic, such as is depicted in FIG. 4 .
- FIG. 9 is a flow chart illustrating an exemplary architecture and functionality of flow control logic, such as is depicted in FIG. 4 .
- FIG. 10 is a flow chart illustrating an exemplary architecture and functionality of packet delivery logic, such as is depicted in FIG. 4 .
- FIG. 1 depicts a communication system 20 that employs a buffering system 30 in accordance with an exemplary embodiment of the present invention in order to buffer data packets that are received from a network 33 .
- the buffering system 30 resides within a receiving unit 35 that is communicatively coupled to the network 33 , and a transmitting unit 38 is configured to transmit at least one sequence of data packets through the network 33 to the receiving unit 35 .
- the buffering system 30 is then configured to temporarily buffer the received data packets before various processing is performed on the data packets by the receiving unit 35 or by various components (not specifically shown) further downstream of the receiving unit 35 .
- system 20 will be described hereafter as communicating graphical data from the transmitting unit 38 to the receiving unit 35 for rendering of the graphical data at the receiving unit 35 .
- system 20 may be described hereafter as communicating graphical data from the transmitting unit 38 to the receiving unit 35 for rendering of the graphical data at the receiving unit 35 .
- other types of data may be communicated by the system 20 and buffered by the buffering system 30 in other embodiments.
- the transmitting unit 38 comprises a graphics application 44 that is configured to produce graphical that is to be communicated to the receiving unit 35 of FIG. 1 .
- the graphics application 44 stores sets of graphical data in different blocks 46 of memory 48 , referred to hereafter as “buffers 46 .”
- the graphics application 44 may produce several image frames and store each of the image frames within a different buffer 46 .
- Packetization logic 52 retrieves graphical data from the buffers 46 and packetizes the retrieved data into data packets. The packetization logic 52 then communicates the data packets to a network interface 55 , which interfaces the data packets with the network 33 such that the data packets are transmitted to the receiving unit 35 .
- each of the transmitted data packets 61 preferably comprises a data portion 63 and a header 66 .
- the packetization logic 52 inserts a portion of the retrieved data in the data portion 63 and inserts various control information within the header 66 for enabling the packet to be communicated through the network 33 to the receiving unit 35 .
- the packetization logic 52 inserts, into the header, an end of buffer indicator 67 , a sequence indicator 68 , and a packet length indicator 70 .
- the end of buffer indicator 67 preferably comprises a pointer, which the packetization logic 52 preferably initializes to a particular value, such as a null value, for example. Utilization of such a pointer will be described in more detail hereafter.
- the packetization logic 52 assigns each packet 61 a sequence indicator 68 that indicates the packet's position within a sequence of packets transmitted from the transmitting unit 38 .
- the packetization logic 52 assigns each packet 61 a sequence indictor 68 that is incremented with respect to the preceding packet 61 packetized by the packetization logic 52 .
- the transmitting unit 38 except when retransmitting a packet 61 in response to a retransmission request, as will be described in more detail hereinbelow, generally transmits packets 61 in the same order that such packets 61 were packetized.
- the difference between the sequence indicators 68 of two packets 61 consecutively transmitted by the transmitting unit 38 is one (1), unless one of the data packets is a retransmission in response to a retransmission request.
- Each data packet 61 also comprises a packet length indicator 70 indicative of the packet's length.
- the packet length indicator 70 may comprise a value corresponding to the number of bytes defining the packet 61 . As an example, if the packet 61 is fifty (50) bytes long, the packet length indicator 70 of the packet 61 may be fifty (50).
- the buffering system 30 of the receiving unit 35 comprises a network interface 81 for receiving, from the network 33 ( FIG. 1 ), the packets transmitted from the transmitting unit 38 .
- the network interface 81 has a network interface card (NIC) 84 comprising hardware components for establishing at least one physical connection with the network 33 .
- the network interface 81 also comprises a network protocol layer 86 , which may be implemented in hardware, software, or any combination thereof. Data received from the network 33 may be read from a data socket 88 of the network protocol layer 86 , and data to be transmitted to the network 33 by the receiving unit 35 may be written to the socket 88 .
- the network protocol layer 86 also preferably comprises a second socket 89 , referred to as a “retransmission socket 89 ,” for handling the retransmissions of missing packets, as will be described in more detail hereinafter.
- Receive logic 92 within the buffering system 30 periodically performs a bulk read of data from the socket 88 and stores the data from this bulk read into one of a plurality of blocks 94 of memory 93 , referred to hereafter as a “buffers 94 .”
- Each buffer 94 is preferably pre-allocated and sized such that the buffer 94 may store a large number (e.g., several hundred) of data packets.
- the buffering system 30 also comprises a buffer pointer pool 98 , which stores a plurality of buffer pointer entries 99 that respectively point to the buffers 94 .
- each pointer entry 99 in the buffer pointer pool 98 preferably has a header 101 and a pointer 102 that points to an available one of the buffers 94 (i.e., one of the buffers 94 that may be written to without corrupting data in the buffer 94 ).
- the buffer pointer pool 98 comprises a pointer entry 99 for each of the buffers 94 .
- the pointer entry 99 associated with (i.e., pointing to) this buffer 94 is pulled from the pool 98 and is not returned to the pool 98 until the buffer 94 is again available.
- the entries 99 of the buffer pointer pool 98 may be analyzed to determine which of the buffers 94 may be written to without corrupting valid data.
- buffers 94 it is not necessary for the buffers 94 to be pre-allocated.
- the receive logic 92 it is possible for the receive logic 92 to dynamically allocate a buffer 94 and an associated pointer entry 99 as packets are received.
- the allocation of buffers 94 and buffer pointer entries 99 consumes time and processing resources potentially slowing the rate at which the receive logic 92 can process data packets.
- slowing the packet processing rate of the receive logic 92 can increase the number of lost data packets thereby resulting in a higher number of retransmission requests that can significantly degrade the performance of the communication system 20 .
- pre-allocating buffers 94 and buffer pointer entries 99 helps to improve the performance of the receive logic 92 and of the system 20 as a whole.
- the receive logic 92 When the receive logic 92 is ready to perform a bulk read of the socket 88 , the receive logic 92 pulls a pointer entry 99 from the buffer pointer pool 98 . The receive logic 92 then performs a bulk read of the socket 88 while writing the data read from the socket 88 into the buffer 94 pointed to by the pointer 102 of the pulled entry 99 . Note that, during this bulk read, a large number (e.g., several hundred) of data packets may be written to the foregoing buffer 94 .
- the receive logic 92 may not be aware of when it has reached the end of the last packet that is to be stored to the foregoing buffer 94 . Therefore, it is possible for the data at the end of the buffer 94 (i.e., the last data stored to the buffer 94 ) to define a partial data packet. Exemplary techniques for accommodating partial packets will be described in more detail hereafter.
- the receive logic 92 scans the data stored in the buffer 94 in order to identify each packet within the buffer 94 .
- the receive logic 92 locates the first packet written to the buffer 94 based on the pointer 102 of the pulled entry 99 .
- the receive logic 92 locates and reads the packet length indicator 70 ( FIG. 3 ) of the first packet. Based on the starting address of the first packet and the packet length indicator 70 of the first packet, the receive logic 92 can determine the memory address where the next sequential packet (i.e., the second packet) is stored.
- the receive logic 92 may scan through the buffer 94 via similar techniques for each packet within the buffer 94 in order to identify each of the packets stored therein.
- the receive logic 92 While the receive logic 92 is identifying the data packets via a scan of the buffer 94 , the receive logic 92 preferably reads the sequence indicator 68 of each packet and provides this information to flow control logic 112 , which will be described in more detail hereinbelow. The receive logic 92 also identifies the last complete packet stored in the buffer 94 . Note that a packet is referred to as “complete” if all of the bytes of the packet are stored in the buffer 94 . Thus, if the number of bytes of the last packet is below the number indicated by the packet's length indicator 70 , then the last packet is a partial packet and is, therefore, not the last complete packet.
- the last complete packet is actually the preceding packet or, in other words, the penultimate packet stored in the buffer.
- the number of bytes of the last packet is equal to the number indicated by the packet's length indicator 70 , then the last packet in the buffer 94 is indeed the last complete packet.
- the receive logic 92 adjusts this packet's end of buffer indicator 67 ( FIG. 3 ) in order to mark this packet as the last complete packet of the buffer 94 .
- the receive logic 92 adjusts the foregoing indicator 67 such that it points to the starting address of the buffer 94 (e.g., the first packet stored in the buffer 94 ).
- the buffer 94 has an indicator 67 initialized to a null value except the last complete packet, which has an indicator 67 pointing to the start of the buffer 94 . Utilization of the adjusted indicator 67 of the last complete packet will be described in more detail hereinbelow.
- the receive logic 92 preferably copies the data of this partial packet to the next buffer 94 to be written into upon the performance of the next bulk read of the socket 88 .
- the receive logic 92 pulls another entry 99 from the buffer pointer pool 98 and writes the partial packet at the first or starting memory address of the buffer 94 pointed to by this entry 99 .
- the receive logic 92 initiates another bulk read of the socket 88 while writing the data read from the socket 88 to the foregoing buffer 94 , and the receive logic 92 repeats the process described above for this buffer 94 .
- the receive logic 92 scans the buffer 94 and identifies the packets stored therein. Then, the receive logic 92 adjusts the end of buffer indicator 67 of the last complete packet and moves the last packet to another buffer 94 , if the last packet is a partial packet.
- the flow control logic 112 may determine whether there are any packets missing from the sequence of packets being read by the current bulk read of the socket 88 .
- the sequence indicator 68 of each data packet transmitted by the transmitting unit 38 is incremented relative to the sequence indicator 68 of the preceding data packet.
- the flow control logic 112 may detect a missing data packet by determining when the sequence indicators 68 of two consecutive data packets processed by the receive logic 92 are not consecutive.
- the flow control logic 112 determines that there are no missing data packets between the first and last packets of the set. In particular, the sequence indicator 68 of each consecutive data packet is incremented relative to the sequence indicator 68 of the preceding packet received before it. However, if the set of sequence indicators 161 instead corresponds to the values of “10,” “101”, and “102,” then the flow control logic 112 preferably detects that a sequence of ninety (90) packets having indicators 68 from eleven (11) to one-hundred (100) is missing.
- the flow control logic 112 When the flow control logic 112 detects a sequence of missing data packets, the logic 112 generates a retransmission request that requests the retransmission of the missing sequence. This retransmission request is transmitted over the network 33 to the transmitting unit 38 , which retransmits the sequence of missing data packets in response to the retransmission request. The retransmitted sequence of missing data packets is received by the receiving unit 35 and stored into a buffer 94 of the receiving unit 35 . Utilization of the foregoing missing packet sequence will be described in more detail hereinbelow.
- the receive logic 92 inserts, into a queue 122 the aforedescribed pulled entry 99 that points to the foregoing buffer 94 .
- the receiving unit 35 for each bulk read of the socket 88 performed by the receive logic 92 , repeats the aforedescribed process of pulling an entry 99 from the pool 98 and then inserting the pulled entry 99 into the queue 122 after writing data from the bulk read to the buffer 94 identified by the pulled entry 99 .
- the queue 122 may comprise several entries 99 that point to buffers 94 storing data packets read from the socket 88 .
- Packet delivery logic 134 is preferably configured to sequentially pull the aforedescribed entries 99 from the queue 122 . For each entry 99 pulled from the queue 122 , the packet delivery logic 134 analyzes the data packets within the buffer 94 pointed to by the entry 99 and determines whether this buffer 94 has a complete sequence of data packets stored therein. Note that a buffer 94 has such a complete sequence of data packets when each packet of the sequence was successfully received by the receiving unit 35 and stored in the buffer 94 .
- the packet delivery logic 134 determines that the buffer 94 identified by the pulled entry 99 is storing an incomplete packet sequence
- the packet delivery logic 134 is configured to construct a complete packet sequence comprising the packets of the incomplete packet sequence as well as the data packets missing from this incomplete packets sequence.
- Various techniques for achieving the foregoing may be performed by the packet delivery logic 134 . Exemplary techniques for constructing a complete packet sequence will now be described in more detail below.
- the flow control logic 112 preferably requests retransmission of missing data packets when such missing data packets are detected by the logic 112 .
- the transmitting unit 38 retransmits the requested packets to the retransmission socket 89 .
- the flow control logic 112 preferably monitors this socket 89 and stores each complete sequence received by this socket 89 to one of the buffers 94 .
- the flow control logic 112 pulls an entry 99 from the buffer pointer pool 98 .
- the logic 112 then reads the retransmitted packet sequence from the socket 89 and stores this sequence in the buffer 94 identified by the pulled entry 99 .
- the flow control logic 112 then stores information indicative of the retransmitted sequence (e.g., information indicative of the range of sequence indicators 68 of the packets in the retransmitted sequence) in the header 101 of the pulled entry and inserts the pulled entry 99 into the queue 122 .
- This entry 99 later will be used by the packet delivery logic 134 to construct a complete packet sequence from the aforementioned incomplete packet sequence.
- the packet delivery logic 134 may pull an entry 99 from the buffer pointer pool 98 and copy, into the buffer 94 identified by this entry 99 , referred to hereafter as the “new buffer 94 ,” each packet of the incomplete packet sequence. Further, the packet delivery logic 134 may search the queue 122 for the entry 99 having a header 101 ( FIG. 5 ) identifying the missing packet sequence. Note that, according to the techniques described above, the flow control logic 112 requests retransmission of the missing packet sequence and inserts the foregoing entry 99 when the logic 112 receives the retransmission of the missing packet sequence.
- the packet delivery logic 134 may pull this entry 99 from the queue 122 and then retrieve the missing packet sequence from the buffer 94 identified by the pulled entry 99 .
- the packet delivery logic 134 may then insert the missing packet sequence into its proper place (i.e., within the hole of the incomplete packet sequence) within the new buffer 94 .
- a complete packet sequence is constructed within the new buffer 94 .
- the packet delivery logic 134 After constructing a complete packet sequence based on an incomplete packet sequence and a missing packet sequence, as described above, the packet delivery logic 134 preferably writes the entries 99 identifying the buffers 94 used to store the incomplete and missing packet sequences into the buffer pointer pool 98 .
- the end of buffer indicator 67 of the last complete packet is preferably set, by the receive logic 92 , to point to the starting address of the buffer 94 in which the last complete packet is stored.
- the packet delivery logic 134 may write, to the buffer pointer pool 98 , an entry 99 pointing to the same address as the indicator 67 of the buffer's last complete data packet (i.e., pointing to the starting address of the buffer 94 ). Such an action has the effect of freeing the foregoing buffers 94 .
- the packet delivery logic 134 preferably transmits, to the rendering element 153 , the entry 99 pointing to the new buffer 94 .
- the rendering element 153 retrieves the complete packet sequence stored in the new buffer 94 and renders the graphical data of this sequence.
- the rendering element 153 preferably comprises a graphics adapter 105 and rendering logic 107 .
- the rendering logic 107 may be configured to drive the graphical data through the graphics adapter 105 , which accelerates and renders the graphical data to the display device 156 ( FIG. 4 ) via known or future-developed techniques.
- the rendering element 153 preferably writes, to the buffer pointer pool 98 , an entry 99 pointing to the new buffer 94 thereby freeing the new buffer 94 for reuse by the receive logic 92 . Similar to the packet delivery logic 134 , the rendering element 153 may utilize the end of buffer indicator 67 of the last complete data packet in the new buffer 94 to define the pointer 102 ( FIG. 5 ) of the entry 99 writing to the pool 98 by the rendering element 153 .
- the flow control logic 112 when the flow control logic 112 receives a retransmission of missing data packets, the flow control logic 112 preferably stores the data of the retransmission into a buffer 94 to the exclusion of other packets that are not part of the missing sequence.
- the foregoing buffer 94 stores only the missing packet sequence.
- Such a feature helps to facilitate construction of a complete packet sequence based on the missing packet sequence and facilitates the configuration of the packet delivery logic 134 .
- storing a missing packet sequence into a buffer 94 to the exclusion of other packets keeps the retransmitted missing data packets separate from other data packets that may not be inserted into the same buffer 94 that is being used to construct the complete packet sequence.
- the transmitting unit 38 may be configured to communicate original transmissions via user datagram protocol-multicast (UDPM) to data socket 88 , and the transmitting unit 38 may be configured to communicate retransmissions via transmission control protocol (TCP) to retransmission socket 89 , although other types of protocols may be employed in other embodiments.
- UDPM user datagram protocol-multicast
- TCP transmission control protocol
- each buffer 94 is preferably identified by only one entry 99 in the pool 98 .
- the receive logic 92 pulls an entry from the pool 98 in order to write into the buffer 94 identified by the entry 99 , as described above, the receive logic 92 is disabled from writing to the same buffer 94 when performing future bulk reads of the socket 88 until the entry 99 is returned to the pool 98 by the either packet delivery logic 134 or the rendering element 153 .
- the receive logic 92 is configured to write into a buffer 94 only when the logic 92 is able to pull the corresponding entry 99 from the pool 98 .
- the receive logic 92 is effectively disabled from writing to the corresponding buffer 94 (i.e., the buffer identified by the foregoing entry 99 ).
- the receive logic 92 is effectively disabled from writing to the corresponding buffer 94 (i.e., the buffer identified by the foregoing entry 99 ).
- the receive logic 92 is configured to write into a buffer 94 only when the logic 92 is able to pull the corresponding entry 99 from the pool 98 .
- buffers 94 storing incomplete packet sequences may be relatively rare.
- the packet delivery logic 134 may simply pass the foregoing entry 99 to the rendering element 153 .
- the rendering element 153 preferably renders the data stored in the buffer 94 identified by the foregoing entry 99 .
- the rendering element 153 also preferably writes the entry 99 to the buffer pointer pool 98 thereby freeing the buffer 94 identified by this entry 99 , as described above.
- the packet delivery logic 134 may first analyze the packets of the corresponding buffer 94 to determine whether the buffer 94 is storing data packets that were packetized via data from multiple buffers 46 ( FIG. 2 ) via the transmitting unit 38 . In some cases, for example, when each buffer 46 stores a different image frame, it may be desirable for each buffer 94 rendered by the rendering element 153 to similarly comprise a different image frame. In such embodiments, the packet delivery logic 134 may be configured to ensure that each entry 99 provided to the rendering element 153 points to a buffer 94 that only stores packets that have been packetized from a single buffer 46 .
- the packet delivery logic 134 may move the packets associated with one of the buffers 46 to a new buffer 94 by pulling a new entry 99 from the buffer pointer pool 98 and storing such packets into the buffer 94 identified by the new entry 99 .
- the entries 99 pointing to each of the foregoing buffers 94 may then be provided to the rendering element 153 , which renders the data in the buffers 94 and then returns the entries 99 to the pool 98 , as described above.
- the packetization logic 52 FIG. 2
- the packetization logic 52 may be configured to insert into each data packet a value indicative of the total number of packets that were packetized via data from the same buffer 46 .
- the network interface 81 , receive logic 92 , flow control logic 112 , packet delivery logic 134 , and rendering element 153 can be implemented in software, hardware, or a combination thereof.
- the network protocol layer 86 , receive logic 92 , flow control logic 112 , packet delivery logic 134 , and rendering logic 107 are implemented in software and stored in memory 93 of a computer system 207 .
- the network protocol layer 86 , receive logic 92 , flow control logic 112 , packet delivery logic 134 , and rendering logic 107 when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch and execute instructions.
- a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution system, apparatus, or device.
- the computer readable-medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.
- the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
- the exemplary embodiment of the computer system 207 depicted by FIG. 7 comprises at least one conventional processing element 212 , such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within the system 207 via a local interface 215 , which can include at least one bus.
- DSP digital signal processor
- CPU central processing unit
- an input device 222 for example, a keyboard or a mouse, can be used to input data from a user of the system 207
- the display device 156 can be used to output data to the user.
- the network protocol layer 86 and receive logic 92 preferably run on a first operating system (OS) thread 232
- the flow control logic 112 and packet delivery logic 134 preferably run on at least one other OS thread 235 that is a thread of execution separate from the OS thread 232 .
- OS operating system
- the OS thread 232 running the receive logic 92 is not burdened with the tasks performed by the flow control logic 112 and the packet delivery logic 134 .
- the graphics application 44 ( FIG. 1 ) writes a set of graphical data to a buffer 46 .
- the packetization logic 52 retrieves this data and then packetizes the data into a plurality of data packets. For each such data packet, the logic 52 initializes the end of buffer indicator 67 ( FIG. 3 ) to a null value, and sets the sequence indicator 68 based on the sequence that the packets are formed and transmitted from the transmitting unit 38 . For example, assume that the packetization logic 52 assigns each packet a sequence indicator 68 that is incremented with respect to the preceding packet formed by the logic 52 .
- the packetization logic 52 After packetizing the graphical data retrieved from the aforementioned buffer 46 , the packetization logic 52 transmits the packets to the network 33 via network interface 55 .
- the packets are preferably transmitted to the network 55 in the same sequence that they were formed such that each transmitted packet generally has a sequence indicator 68 with a higher value as compared to the sequence indicators 68 of the packets transmitted before it.
- sequence indicators 68 of the transmitted packets it is possible to determine the sequence that the packets were transmitted from the transmitting unit 38 .
- the receive logic 92 When the transmitted sequence of packets arrives at the receiving unit 35 , the packets are received by the socket 88 ( FIG. 4 ). As shown by decision block 312 and blocks 313 and 314 of FIG. 8 , the receive logic 92 performs a bulk read of the socket 88 thereby storing at least a portion of the transmission sequence into one of the pre-allocated buffers 94 . In this regard, the receive logic 92 pulls a buffer pointer entry 99 from the buffer pointer pool 98 and writes the data read from the socket 88 during the bulk read to the buffer 94 identified by the pointer 102 ( FIG. 5 ) of the pulled entry 99 .
- the receive logic 92 preferably continues with the bulk read until the foregoing buffer 94 is full or until all of the data has been read from the socket 88 . Note that pulling the entry 99 from the pool 98 has the effect of disabling the receive logic 92 from overwriting the data stored in the foregoing buffer 94 until an entry 99 with the same pointer 102 is later inserted into the buffer pointer pool 98 .
- the receive logic 92 scans the buffer 94 and identifies each packet within the buffer 94 , including the last complete packet stored in the buffer 94 , as shown by block 317 . While scanning the buffer 94 , the receive logic 92 provides, to the flow control logic 112 , the sequence indicator 68 of each packet in the buffer 94 . As will be described in more detail hereinbelow, the flow control logic 112 determines whether there are any data packets missing from the sequence of packets stored in the buffer 94 .
- the receive logic 92 updates the end of buffer indicator 67 ( FIG. 3 ) of the last complete data packet stored in the buffer 94 such that this indicator 67 points to the first memory address of the buffer 94 .
- the indicator 67 indicates that its data packet is the last complete packet of the buffer 94 or, in other words, that the foregoing packet is not followed in the buffer 94 by a complete data packet.
- the receive logic 92 determines whether the last packet stored in the buffer 94 is an incomplete or partial packet. If so, the receive logic 92 copies the data defining the partial packet into the next buffer 94 to be used for storing the data from the next successive bulk read performed by the receive logic 92 . In this regard, in block 324 , the receive logic 92 pulls, from the buffer pointer pool 98 , an entry 99 , referred to hereafter as the “new entry 99 .” The receive logic 92 then writes the partial packet into the first memory address of the buffer 94 , referred to hereafter as the “new buffer 94 ,” identified by the new entry 99 , as shown by block 327 .
- the receive logic 92 inserts, into the queue 122 , the pointer entry 99 that points to the scanned buffer 94 (i.e., the pointer entry 99 previously described as being pulled from the pool 98 in block 313 ), as shown by block 329 .
- the receive logic 92 then proceeds to block 314 and performs a bulk read of the socket 88 .
- the first set of data read during this bulk read corresponds to the remaining portion of the partial packet copied to the new buffer 94 in block 327 .
- This first set of data is preferably written immediately following the partial packet such that the partial packet is transformed into a complete packet via the addition of the first set of data.
- the remainder of the data read from the socket 88 may be stored in the following memory addresses of the new buffer 94 until the new buffer 94 is full or until the socket 88 is empty.
- receive logic 92 determines, in decision block 321 , that the last packet is not incomplete, then receive logic 92 skips steps 324 and 327 .
- the receive logic inserts, into the queue 122 , the pointer entry 99 that points to the scanned buffer 94 (i.e., the pointer entry 99 previously described as being pulled from the pool 98 in block 313 ).
- the receive logic 92 returns to block 312 and repeats the aforedescribed process such that data read from the socket 88 , via another bulk read, is stored into a different buffer 94 .
- the receive logic 92 transmits, to the flow control logic 112 , the sequence indicators 68 of the packets stored in the buffer 94 being scanned via block 317 . Based on this information, the flow control logic 112 determines whether there are any data packets missing from the sequence stored in the foregoing buffer 94 , as shown by decision blocks 352 and 354 of FIG. 9 . If there is a missing sequence of data packets, the flow control logic 112 submits a retransmission request, as shown by block 357 .
- the foregoing retransmission request is communicated to the transmitting unit 38 ( FIG. 1 ) and identifies the missing sequence of packets.
- the transmitting unit 38 retransmits the missing sequence of packets.
- the retransmitted sequence of data packets preferably arrives at the retransmission socket 89 , and the flow control logic 112 stores the retransmitted sequence to a buffer 94 that is temporarily dedicated to this sequence.
- the flow control logic 112 pulls a buffer pointer entry 99 from the buffer pointer pool 98 and writes the entire retransmitted sequence into the buffer 94 identified by the pulled entry 99 , as shown by decision blocks 362 , 363 and 367 .
- the flow control logic 112 preferably adjusts the end of buffer indicator 67 ( FIG. 3 ) of the last packet of the retransmitted sequence such that the indicator 67 points to the first address of the foregoing buffer 94 thereby indicating that this packet is the last packet of the buffer 94 .
- the flow control logic 112 then inserts, into the queue 122 , the pulled entry 99 that identifies the buffer 94 storing the retransmitted sequence, as shown by block 376 .
- the flow control logic 112 preferably inserts, into the entry's header 101 ( FIG. 5 ), information indicating that the entry 99 points to the missing packet sequence.
- the information may indicate the range of sequence indicators 68 of the packets stored in the buffer 94 identified by the foregoing entry 99 .
- the packet delivery logic 134 checks the queue 122 and pulls an entry 99 from the queue 122 if such an entry 99 is available. The packet delivery logic 134 then scans the buffer 94 identified by the entry 99 and determines whether there are any data packets missing from the packet sequence stored in the scanned buffer 94 , as shown by blocks 412 and 415 . If there are no missing packets, the packet delivery logic 134 , as shown by block 422 , provides the entry 99 pulled from the queue 122 via block 408 to the rendering element 153 ( FIG. 4 ). The rendering element 153 then renders the data stored in the buffer 94 identified by the foregoing entry 99 . Upon rendering such data, the rendering element 153 returns the entry 99 to the buffer pointer pool 98 thereby freeing the foregoing buffer 94 .
- the packet delivery logic 134 detects that a sequence of data packets are missing from the foregoing buffer 94 or, in other words, detects that the sequence of data packets in the buffer 94 is incomplete, then the logic 134 pulls an entry 99 , referred to as “new entry 99 ,” from the pool 98 in block 430 and constructs a complete packet sequence in block 431 .
- the packet delivery logic 134 locates and retrieves the missing packet sequence and combines this missing packet sequence with the incomplete packet sequence to form a complete packet sequence.
- the logic 134 stores the complete packet sequence into the buffer 94 , referred to as the “new buffer 94 ,” that is identified by the new entry 99 .
- the incomplete packet sequence has indicators 68 ranging consecutively from one-hundred (100) to one-hundred-fifty (150) and from three-hundred (300) to four-hundred (400).
- the buffer 94 storing this sequence is missing the packets having sequence indicators 68 ranging from 151 through 299.
- the flow control logic 112 requests retransmission of the missing packet sequence (i.e., the packets having sequence indicators 68 ranging consecutively from one-hundred-fifty-one (151) to two-hundred-ninety-nine (299)) in block 357 of FIG. 9 .
- the flow control logic 112 also stores the missing packet sequence to one of the buffers 94 in block 367 and inserts, into the queue 122 , an entry 99 identifying this buffer 94 .
- the packet delivery logic 134 locates the forgoing entry 99 based on the entry's header 101 and then pulls this entry 99 from the queue 122 .
- the packet delivery logic 134 then retrieves the missing packet sequence from the buffer 94 identified by the foregoing entry 99 and writes these packets, along with the incomplete packet sequence stored in the buffer 94 scanned via block 412 , into the new buffer 94 . Therefore, the new buffer 94 stores the complete packet sequence (i.e., a packet sequence having each indicator 68 ranging consecutively from one-hundred (100) to four-hundred (400)).
- the packet delivery logic 134 returns the two entries 99 that identify the buffers 94 storing the missing packet sequence and the incomplete packet sequence. Further, in block 439 , the packet delivery logic 134 provides the remaining entry 99 (i.e., the new entry 99 that points to the new buffer 94 , which is storing the complete packet sequence) to the rendering element 153 . The rendering element 153 then renders the graphical data stored in the new buffer 94 and returns the new entry 99 to buffer pointer pool 98 thereby freeing the new buffer 94 . Thus, the packet delivery logic 134 ensures that each entry 99 provided to the rendering element 153 points to a buffer 94 storing a complete packet sequence.
Abstract
A system for buffering data received from a network comprises a network socket, a plurality of buffers, a buffer pointer pool, receive logic, and packet delivery logic. The buffer pointer pool has a plurality of entries respectively pointing to the buffers. The receive logic is configured to pull an entry from the pool and to perform a bulk read of the network socket. The entry points to one of the buffers, and the receive logic is further configured to store data from the bulk read to the one buffer based on the entry. The packet delivery logic is configured to read, based on the entry, the one buffer and to locate a missing packet sequence in response to a determination, by the packet delivery logic, that the one buffer is storing an incomplete packet sequence. The packet delivery logic is further configured to form a complete packet sequence based on the incomplete packet sequence and the missing packet sequence.
Description
- This application is a divisional of U.S. patent application Ser. No. 10/361,742, entitled “System and Method for Buffering Data Received from a Network,” and filed on Feb. 8, 2003, which is incorporated herein by reference.
- In some communication systems, such as networked graphical rendering systems, for example, large amounts of data are transmitted from a transmitting unit through a network to at least one receiving unit. For example, a graphics application at a transmitting unit may transmit graphical data to at least one remote receiving unit that renders the graphical data to form a rendered image. In such a system, communication of large amounts of graphical data at a relatively high transmission rate may be needed in order to provide a suitable frame rate for the rendered image.
- Performance of a system's transmitting and receiving units in transmitting data to and receiving data from a network is typically an important factor in whether graphical data can be successfully rendered via a remote receiving unit at suitable frame rates. Unfortunately, achieving a suitable transmission rate for the data communicated from the transmitting unit to the receiving unit or units can sometimes be problematic, particularly in instances where a large number of receiving units are to receive the graphical data. In such situations, the transmitting unit may be configured to transmit each graphics command multiple times through the network (e.g., once for each destination receiving unit that is to receive the command). The multiple transmissions of the graphics commands can significantly increase the amount of data that is to be communicated through the network.
- Thus, better techniques for communicating with a network to achieve a higher network throughput are generally desirable. Generally, embodiments of the present invention provide a system and method for buffering data received from a network.
- An exemplary system in accordance with one embodiment of the present invention comprises a network socket and receive logic. The receive logic is configured to perform a bulk read of the network socket and to store data from the bulk read into one of a plurality of buffers. The receive logic is further configured to perform a scan of the one buffer and to detect, based on the scan, a partial packet stored in the one buffer. The receive logic is further configured to write the partial packet to a second one of the buffers in response to a detection of the partial packet.
- Another exemplary system in accordance with another embodiment of the present invention comprises a network socket, a plurality of buffers, a buffer pointer pool, receive logic, and packet delivery logic. The buffer pointer pool has a plurality of entries respectively pointing to the buffers. The receive logic is configured to pull an entry from the pool and to perform a bulk read of the network socket. The entry points to one of the buffers, and the receive logic is further configured to store data from the bulk read to the one buffer based on the entry. The packet delivery logic is configured to read, based on the entry, the one buffer and to locate a missing packet sequence in response to a determination, by the packet delivery logic, that the one buffer is storing an incomplete packet sequence. The packet delivery logic is further configured to form a complete packet sequence based on the incomplete packet sequence and the missing packet sequence.
- The invention can be better understood with reference to the following drawings. The elements of the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the invention. Furthermore, like reference numerals designate corresponding parts throughout the several views.
-
FIG. 1 is a block diagram illustrating an exemplary communication system in accordance with the present invention. -
FIG. 2 is a block diagram illustrating an exemplary transmitting unit, such as is depicted inFIG. 1 . -
FIG. 3 is a block diagram illustrating an exemplary data packet that may be transmitted from a transmitting unit, such as is depicted inFIG. 2 . -
FIG. 4 is a block diagram illustrating an exemplary buffering system, such as is depicted inFIG. 1 . -
FIG. 5 is a block diagram illustrating an exemplary buffer pointer entry, such as is depicted inFIG. 4 . -
FIG. 6 is a block diagram illustrating an exemplary rendering element, such as is depicted inFIG. 4 . -
FIG. 7 is block diagram illustrating an exemplary computer system that may be used to implement a buffering system, such as is depicted inFIG. 4 . -
FIG. 8 is a flow chart illustrating an exemplary architecture and functionality of receive logic, such as is depicted inFIG. 4 . -
FIG. 9 is a flow chart illustrating an exemplary architecture and functionality of flow control logic, such as is depicted inFIG. 4 . -
FIG. 10 is a flow chart illustrating an exemplary architecture and functionality of packet delivery logic, such as is depicted inFIG. 4 . - The present invention generally pertains to a system and method for efficiently buffering data packets. Indeed,
FIG. 1 depicts acommunication system 20 that employs abuffering system 30 in accordance with an exemplary embodiment of the present invention in order to buffer data packets that are received from anetwork 33. As shown byFIG. 1 , thebuffering system 30 resides within areceiving unit 35 that is communicatively coupled to thenetwork 33, and a transmittingunit 38 is configured to transmit at least one sequence of data packets through thenetwork 33 to thereceiving unit 35. Thebuffering system 30 is then configured to temporarily buffer the received data packets before various processing is performed on the data packets by the receivingunit 35 or by various components (not specifically shown) further downstream of thereceiving unit 35. - For illustrative purposes, the
system 20 will be described hereafter as communicating graphical data from the transmittingunit 38 to the receivingunit 35 for rendering of the graphical data at thereceiving unit 35. However, it should be emphasized that other types of data may be communicated by thesystem 20 and buffered by thebuffering system 30 in other embodiments. - As shown by
FIG. 2 , the transmittingunit 38 comprises agraphics application 44 that is configured to produce graphical that is to be communicated to the receivingunit 35 ofFIG. 1 . During operation, thegraphics application 44 stores sets of graphical data indifferent blocks 46 ofmemory 48, referred to hereafter as “buffers 46.” As an example, thegraphics application 44 may produce several image frames and store each of the image frames within adifferent buffer 46. -
Packetization logic 52 retrieves graphical data from thebuffers 46 and packetizes the retrieved data into data packets. Thepacketization logic 52 then communicates the data packets to anetwork interface 55, which interfaces the data packets with thenetwork 33 such that the data packets are transmitted to the receivingunit 35. - As shown by
FIG. 3 , each of the transmitteddata packets 61 preferably comprises adata portion 63 and aheader 66. When packetizing the graphical data retrieved from thebuffers 46, thepacketization logic 52 inserts a portion of the retrieved data in thedata portion 63 and inserts various control information within theheader 66 for enabling the packet to be communicated through thenetwork 33 to thereceiving unit 35. In the exemplary embodiment depicted byFIG. 3 , thepacketization logic 52 inserts, into the header, an end ofbuffer indicator 67, asequence indicator 68, and apacket length indicator 70. - The end of
buffer indicator 67 preferably comprises a pointer, which thepacketization logic 52 preferably initializes to a particular value, such as a null value, for example. Utilization of such a pointer will be described in more detail hereafter. - To uniquely identify each
packet 61, thepacketization logic 52 assigns each packet 61 asequence indicator 68 that indicates the packet's position within a sequence of packets transmitted from the transmittingunit 38. In an exemplary embodiment, thepacketization logic 52 assigns each packet 61 asequence indictor 68 that is incremented with respect to the precedingpacket 61 packetized by thepacketization logic 52. Further, the transmittingunit 38, except when retransmitting apacket 61 in response to a retransmission request, as will be described in more detail hereinbelow, generally transmitspackets 61 in the same order thatsuch packets 61 were packetized. Thus, in general, the difference between thesequence indicators 68 of twopackets 61 consecutively transmitted by the transmittingunit 38 is one (1), unless one of the data packets is a retransmission in response to a retransmission request. - Each
data packet 61 also comprises apacket length indicator 70 indicative of the packet's length. For example, thepacket length indicator 70 may comprise a value corresponding to the number of bytes defining thepacket 61. As an example, if thepacket 61 is fifty (50) bytes long, thepacket length indicator 70 of thepacket 61 may be fifty (50). - As shown by
FIG. 4 , thebuffering system 30 of thereceiving unit 35 comprises anetwork interface 81 for receiving, from the network 33 (FIG. 1 ), the packets transmitted from the transmittingunit 38. In one exemplary embodiment, thenetwork interface 81 has a network interface card (NIC) 84 comprising hardware components for establishing at least one physical connection with thenetwork 33. Thenetwork interface 81 also comprises anetwork protocol layer 86, which may be implemented in hardware, software, or any combination thereof. Data received from thenetwork 33 may be read from adata socket 88 of thenetwork protocol layer 86, and data to be transmitted to thenetwork 33 by the receivingunit 35 may be written to thesocket 88. As shown byFIG. 4 , thenetwork protocol layer 86 also preferably comprises a second socket 89, referred to as a “retransmission socket 89,” for handling the retransmissions of missing packets, as will be described in more detail hereinafter. - Receive
logic 92 within thebuffering system 30 periodically performs a bulk read of data from thesocket 88 and stores the data from this bulk read into one of a plurality ofblocks 94 ofmemory 93, referred to hereafter as a “buffers 94.” Eachbuffer 94 is preferably pre-allocated and sized such that thebuffer 94 may store a large number (e.g., several hundred) of data packets. Furthermore, thebuffering system 30 also comprises abuffer pointer pool 98, which stores a plurality ofbuffer pointer entries 99 that respectively point to thebuffers 94. - In this regard, as shown by
FIG. 5 , eachpointer entry 99 in thebuffer pointer pool 98 preferably has aheader 101 and apointer 102 that points to an available one of the buffers 94 (i.e., one of thebuffers 94 that may be written to without corrupting data in the buffer 94). Initially, all of thebuffers 94 are available, and thebuffer pointer pool 98 comprises apointer entry 99 for each of thebuffers 94. However, when abuffer 94 is written to, as will be described in more detail hereinbelow, thepointer entry 99 associated with (i.e., pointing to) thisbuffer 94 is pulled from thepool 98 and is not returned to thepool 98 until thebuffer 94 is again available. Thus, theentries 99 of thebuffer pointer pool 98 may be analyzed to determine which of thebuffers 94 may be written to without corrupting valid data. - Note that it is not necessary for the
buffers 94 to be pre-allocated. In this regard, it is possible for the receivelogic 92 to dynamically allocate abuffer 94 and an associatedpointer entry 99 as packets are received. However, the allocation ofbuffers 94 andbuffer pointer entries 99 consumes time and processing resources potentially slowing the rate at which the receivelogic 92 can process data packets. Furthermore, slowing the packet processing rate of the receivelogic 92 can increase the number of lost data packets thereby resulting in a higher number of retransmission requests that can significantly degrade the performance of thecommunication system 20. Thus,pre-allocating buffers 94 andbuffer pointer entries 99 helps to improve the performance of the receivelogic 92 and of thesystem 20 as a whole. - When the receive
logic 92 is ready to perform a bulk read of thesocket 88, the receivelogic 92 pulls apointer entry 99 from thebuffer pointer pool 98. The receivelogic 92 then performs a bulk read of thesocket 88 while writing the data read from thesocket 88 into thebuffer 94 pointed to by thepointer 102 of the pulledentry 99. Note that, during this bulk read, a large number (e.g., several hundred) of data packets may be written to the foregoingbuffer 94. - Furthermore, to reduce the time it takes for the receive
logic 92 to read data from of thesocket 88, it is desirable for the receivelogic 92 to perform the bulk read without performing multiple passes of the data on thesocket 88. However, without performing multiple passes of such data, the receivelogic 92 may not be aware of when it has reached the end of the last packet that is to be stored to the foregoingbuffer 94. Therefore, it is possible for the data at the end of the buffer 94 (i.e., the last data stored to the buffer 94) to define a partial data packet. Exemplary techniques for accommodating partial packets will be described in more detail hereafter. - After performing the bulk read, the receive
logic 92 scans the data stored in thebuffer 94 in order to identify each packet within thebuffer 94. In this regard, the receivelogic 92 locates the first packet written to thebuffer 94 based on thepointer 102 of the pulledentry 99. The receivelogic 92 then locates and reads the packet length indicator 70 (FIG. 3 ) of the first packet. Based on the starting address of the first packet and thepacket length indicator 70 of the first packet, the receivelogic 92 can determine the memory address where the next sequential packet (i.e., the second packet) is stored. The receivelogic 92 may scan through thebuffer 94 via similar techniques for each packet within thebuffer 94 in order to identify each of the packets stored therein. - While the receive
logic 92 is identifying the data packets via a scan of thebuffer 94, the receivelogic 92 preferably reads thesequence indicator 68 of each packet and provides this information to flowcontrol logic 112, which will be described in more detail hereinbelow. The receivelogic 92 also identifies the last complete packet stored in thebuffer 94. Note that a packet is referred to as “complete” if all of the bytes of the packet are stored in thebuffer 94. Thus, if the number of bytes of the last packet is below the number indicated by the packet'slength indicator 70, then the last packet is a partial packet and is, therefore, not the last complete packet. In such an example, the last complete packet is actually the preceding packet or, in other words, the penultimate packet stored in the buffer. However, if the number of bytes of the last packet is equal to the number indicated by the packet'slength indicator 70, then the last packet in thebuffer 94 is indeed the last complete packet. - After identifying the last complete packet, the receive
logic 92 adjusts this packet's end of buffer indicator 67 (FIG. 3 ) in order to mark this packet as the last complete packet of thebuffer 94. In one exemplary embodiment, the receivelogic 92 adjusts the foregoingindicator 67 such that it points to the starting address of the buffer 94 (e.g., the first packet stored in the buffer 94). Thus, all of the packets stored in thebuffer 94 have anindicator 67 initialized to a null value except the last complete packet, which has anindicator 67 pointing to the start of thebuffer 94. Utilization of the adjustedindicator 67 of the last complete packet will be described in more detail hereinbelow. - If the last packet of the
buffer 94 is a partial packet and, therefore, not the last complete packet of thebuffer 94, then the receivelogic 92 preferably copies the data of this partial packet to thenext buffer 94 to be written into upon the performance of the next bulk read of thesocket 88. Thus, the receivelogic 92 pulls anotherentry 99 from thebuffer pointer pool 98 and writes the partial packet at the first or starting memory address of thebuffer 94 pointed to by thisentry 99. Then, the receivelogic 92 initiates another bulk read of thesocket 88 while writing the data read from thesocket 88 to the foregoingbuffer 94, and the receivelogic 92 repeats the process described above for thisbuffer 94. In other words, the receivelogic 92 scans thebuffer 94 and identifies the packets stored therein. Then, the receivelogic 92 adjusts the end ofbuffer indicator 67 of the last complete packet and moves the last packet to anotherbuffer 94, if the last packet is a partial packet. - Based on the
sequence indicators 68 provided to it by the receivelogic 92, theflow control logic 112 may determine whether there are any packets missing from the sequence of packets being read by the current bulk read of thesocket 88. In this regard, in the example described above, thesequence indicator 68 of each data packet transmitted by the transmittingunit 38 is incremented relative to thesequence indicator 68 of the preceding data packet. In such an example, theflow control logic 112 may detect a missing data packet by determining when thesequence indicators 68 of two consecutive data packets processed by the receivelogic 92 are not consecutive. - For example, if a set of three consecutively received data packets have
sequence indicators 68 corresponding to the values of “10,” “11,” and “12,” then theflow control logic 112 determines that there are no missing data packets between the first and last packets of the set. In particular, thesequence indicator 68 of each consecutive data packet is incremented relative to thesequence indicator 68 of the preceding packet received before it. However, if the set of sequence indicators 161 instead corresponds to the values of “10,” “101”, and “102,” then theflow control logic 112 preferably detects that a sequence of ninety (90)packets having indicators 68 from eleven (11) to one-hundred (100) is missing. - When the
flow control logic 112 detects a sequence of missing data packets, thelogic 112 generates a retransmission request that requests the retransmission of the missing sequence. This retransmission request is transmitted over thenetwork 33 to the transmittingunit 38, which retransmits the sequence of missing data packets in response to the retransmission request. The retransmitted sequence of missing data packets is received by the receivingunit 35 and stored into abuffer 94 of the receivingunit 35. Utilization of the foregoing missing packet sequence will be described in more detail hereinbelow. - Once the receive
logic 92 has completed a bulk read of thesocket 88 and has stored the data from the bulk read into abuffer 94, as described above, the receivelogic 92 inserts, into aqueue 122 the aforedescribed pulledentry 99 that points to the foregoingbuffer 94. The receivingunit 35, for each bulk read of thesocket 88 performed by the receivelogic 92, repeats the aforedescribed process of pulling anentry 99 from thepool 98 and then inserting the pulledentry 99 into thequeue 122 after writing data from the bulk read to thebuffer 94 identified by the pulledentry 99. Thus, thequeue 122 may compriseseveral entries 99 that point tobuffers 94 storing data packets read from thesocket 88. -
Packet delivery logic 134 is preferably configured to sequentially pull theaforedescribed entries 99 from thequeue 122. For eachentry 99 pulled from thequeue 122, thepacket delivery logic 134 analyzes the data packets within thebuffer 94 pointed to by theentry 99 and determines whether thisbuffer 94 has a complete sequence of data packets stored therein. Note that abuffer 94 has such a complete sequence of data packets when each packet of the sequence was successfully received by the receivingunit 35 and stored in thebuffer 94. - When the
packet delivery logic 134 determines that thebuffer 94 identified by the pulledentry 99 is storing an incomplete packet sequence, thepacket delivery logic 134 is configured to construct a complete packet sequence comprising the packets of the incomplete packet sequence as well as the data packets missing from this incomplete packets sequence. Various techniques for achieving the foregoing may be performed by thepacket delivery logic 134. Exemplary techniques for constructing a complete packet sequence will now be described in more detail below. - In this regard, as described above, the
flow control logic 112 preferably requests retransmission of missing data packets when such missing data packets are detected by thelogic 112. In response, the transmittingunit 38 retransmits the requested packets to the retransmission socket 89. Theflow control logic 112 preferably monitors this socket 89 and stores each complete sequence received by this socket 89 to one of thebuffers 94. In this regard, when a retransmitted packet sequence received by the socket 89, theflow control logic 112 pulls anentry 99 from thebuffer pointer pool 98. Thelogic 112 then reads the retransmitted packet sequence from the socket 89 and stores this sequence in thebuffer 94 identified by the pulledentry 99. Theflow control logic 112 then stores information indicative of the retransmitted sequence (e.g., information indicative of the range ofsequence indicators 68 of the packets in the retransmitted sequence) in theheader 101 of the pulled entry and inserts the pulledentry 99 into thequeue 122. Thisentry 99 later will be used by thepacket delivery logic 134 to construct a complete packet sequence from the aforementioned incomplete packet sequence. - More specifically, in constructing such a complete packet sequence, the
packet delivery logic 134 may pull anentry 99 from thebuffer pointer pool 98 and copy, into thebuffer 94 identified by thisentry 99, referred to hereafter as the “new buffer 94,” each packet of the incomplete packet sequence. Further, thepacket delivery logic 134 may search thequeue 122 for theentry 99 having a header 101 (FIG. 5 ) identifying the missing packet sequence. Note that, according to the techniques described above, theflow control logic 112 requests retransmission of the missing packet sequence and inserts the foregoingentry 99 when thelogic 112 receives the retransmission of the missing packet sequence. When thepacket delivery logic 134 locates theentry 99 having aheader 101 identifying the missing packet sequence, thelogic 134 may pull thisentry 99 from thequeue 122 and then retrieve the missing packet sequence from thebuffer 94 identified by the pulledentry 99. Thepacket delivery logic 134 may then insert the missing packet sequence into its proper place (i.e., within the hole of the incomplete packet sequence) within thenew buffer 94. Thus, a complete packet sequence is constructed within thenew buffer 94. - After constructing a complete packet sequence based on an incomplete packet sequence and a missing packet sequence, as described above, the
packet delivery logic 134 preferably writes theentries 99 identifying thebuffers 94 used to store the incomplete and missing packet sequences into thebuffer pointer pool 98. In this regard, as described above, the end ofbuffer indicator 67 of the last complete packet is preferably set, by the receivelogic 92, to point to the starting address of thebuffer 94 in which the last complete packet is stored. For each of the foregoing buffers 94, thepacket delivery logic 134 may write, to thebuffer pointer pool 98, anentry 99 pointing to the same address as theindicator 67 of the buffer's last complete data packet (i.e., pointing to the starting address of the buffer 94). Such an action has the effect of freeing the foregoing buffers 94. - Further, after constructing a complete packet sequence, as described above, the
packet delivery logic 134 preferably transmits, to therendering element 153, theentry 99 pointing to thenew buffer 94. In response, therendering element 153 retrieves the complete packet sequence stored in thenew buffer 94 and renders the graphical data of this sequence. In this regard, as shown byFIG. 6 , therendering element 153 preferably comprises agraphics adapter 105 andrendering logic 107. Therendering logic 107 may be configured to drive the graphical data through thegraphics adapter 105, which accelerates and renders the graphical data to the display device 156 (FIG. 4 ) via known or future-developed techniques. Note that after graphical data from thenew buffer 94 is retrieved, therendering element 153 preferably writes, to thebuffer pointer pool 98, anentry 99 pointing to thenew buffer 94 thereby freeing thenew buffer 94 for reuse by the receivelogic 92. Similar to thepacket delivery logic 134, therendering element 153 may utilize the end ofbuffer indicator 67 of the last complete data packet in thenew buffer 94 to define the pointer 102 (FIG. 5 ) of theentry 99 writing to thepool 98 by therendering element 153. - Note that when the
flow control logic 112 receives a retransmission of missing data packets, theflow control logic 112 preferably stores the data of the retransmission into abuffer 94 to the exclusion of other packets that are not part of the missing sequence. Thus, the foregoingbuffer 94 stores only the missing packet sequence. Such a feature helps to facilitate construction of a complete packet sequence based on the missing packet sequence and facilitates the configuration of thepacket delivery logic 134. In this regard, storing a missing packet sequence into abuffer 94 to the exclusion of other packets keeps the retransmitted missing data packets separate from other data packets that may not be inserted into thesame buffer 94 that is being used to construct the complete packet sequence. - In addition, it should be noted that different protocols may be used to communicate retransmissions as compared to original transmissions of data packets. For example, the transmitting
unit 38 may be configured to communicate original transmissions via user datagram protocol-multicast (UDPM) todata socket 88, and the transmittingunit 38 may be configured to communicate retransmissions via transmission control protocol (TCP) to retransmission socket 89, although other types of protocols may be employed in other embodiments. - It should be further noted that writing an
entry 99 into thepool 98, as described above, has the effect of freeing the corresponding buffer 94 (i.e., thebuffer 94 identified by the entry 99) for reuse by the receivelogic 92. In this regard, eachbuffer 94 is preferably identified by only oneentry 99 in thepool 98. Thus, when the receivelogic 92 pulls an entry from thepool 98 in order to write into thebuffer 94 identified by theentry 99, as described above, the receivelogic 92 is disabled from writing to thesame buffer 94 when performing future bulk reads of thesocket 88 until theentry 99 is returned to thepool 98 by the eitherpacket delivery logic 134 or therendering element 153. In this regard, the receivelogic 92 is configured to write into abuffer 94 only when thelogic 92 is able to pull thecorresponding entry 99 from thepool 98. Thus, if acorresponding entry 99 is not in thepool 98, then the receivelogic 92 is effectively disabled from writing to the corresponding buffer 94 (i.e., the buffer identified by the foregoing entry 99). As result, by pullingentries 99 from thepool 98 and not returning theentries 99 to the pool until the data stored in the corresponding buffers 94 has been retrieved and used by either thepacket delivery logic 134 or therendering element 153, corruption of valid data in thebuffers 94 by the receivelogic 92 is prevented. - In addition, it should be noted that not all
buffers 94 storing data from a bulk read will have an incomplete sequence stored therein. Indeed, by using techniques, such as those described herein, for increasing the rate at which the receivelogic 92 is able to read packets off of thesocket 88, buffers 94 storing incomplete packet sequences may be relatively rare. In any event, when thepacket delivery logic 134 determines, after pulling anentry 99 from thequeue 122, that thebuffer 94 identified by theentry 99 is storing a complete packet sequence, thepacket delivery logic 134 may simply pass the foregoingentry 99 to therendering element 153. In response, therendering element 153 preferably renders the data stored in thebuffer 94 identified by the foregoingentry 99. Therendering element 153 also preferably writes theentry 99 to thebuffer pointer pool 98 thereby freeing thebuffer 94 identified by thisentry 99, as described above. - Furthermore, before providing an
entry 99 to therendering element 153, thepacket delivery logic 134 may first analyze the packets of the correspondingbuffer 94 to determine whether thebuffer 94 is storing data packets that were packetized via data from multiple buffers 46 (FIG. 2 ) via the transmittingunit 38. In some cases, for example, when eachbuffer 46 stores a different image frame, it may be desirable for eachbuffer 94 rendered by therendering element 153 to similarly comprise a different image frame. In such embodiments, thepacket delivery logic 134 may be configured to ensure that eachentry 99 provided to therendering element 153 points to abuffer 94 that only stores packets that have been packetized from asingle buffer 46. - As an example, if a
buffer 94 stores packets packetized via data from twobuffers 46, thepacket delivery logic 134 may move the packets associated with one of thebuffers 46 to anew buffer 94 by pulling anew entry 99 from thebuffer pointer pool 98 and storing such packets into thebuffer 94 identified by thenew entry 99. Theentries 99 pointing to each of the foregoing buffers 94 may then be provided to therendering element 153, which renders the data in thebuffers 94 and then returns theentries 99 to thepool 98, as described above. Note that to enable thepacket delivery logic 153 to determine whether the packets in abuffer 94 have been packetized from thesame buffer 46, the packetization logic 52 (FIG. 2 ) may be configured to insert into each data packet a value indicative of the total number of packets that were packetized via data from thesame buffer 46. - It should be noted that the
network interface 81, receivelogic 92,flow control logic 112,packet delivery logic 134, andrendering element 153 can be implemented in software, hardware, or a combination thereof. In an exemplary embodiment illustrated inFIG. 7 , thenetwork protocol layer 86, receivelogic 92,flow control logic 112,packet delivery logic 134, andrendering logic 107, along with their associated methodology, are implemented in software and stored inmemory 93 of acomputer system 207. - Note that the
network protocol layer 86, receivelogic 92,flow control logic 112,packet delivery logic 134, andrendering logic 107, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch and execute instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable-medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory. - The exemplary embodiment of the
computer system 207 depicted byFIG. 7 comprises at least oneconventional processing element 212, such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within thesystem 207 via alocal interface 215, which can include at least one bus. Furthermore, aninput device 222, for example, a keyboard or a mouse, can be used to input data from a user of thesystem 207, and thedisplay device 156, can be used to output data to the user. - As shown by
FIG. 7 , thenetwork protocol layer 86 and receivelogic 92 preferably run on a first operating system (OS)thread 232, and theflow control logic 112 andpacket delivery logic 134 preferably run on at least oneother OS thread 235 that is a thread of execution separate from theOS thread 232. Note that having the receivelogic 92 run on athread 232 different than the one used to run theflow control logic 112 and thepacket delivery logic 134 can help to improve the operational performance of the receivingunit 35. In such an embodiment, theOS thread 232 running the receivelogic 92 is not burdened with the tasks performed by theflow control logic 112 and thepacket delivery logic 134. Thus, tasks performed by theflow control logic 112 and thepacket delivery logic 134 do not substantially usurp the processing resources used to run the receivelogic 92. As a result, the receivelogic 92 is able to process data packets at a faster rate thereby potentially decreasing the number of retransmission requests generated by theflow control logic 112. - An exemplary use and operation of the
communication system 20 and associated methodology are described hereafter. - Initially, the graphics application 44 (
FIG. 1 ) writes a set of graphical data to abuffer 46. Thepacketization logic 52 retrieves this data and then packetizes the data into a plurality of data packets. For each such data packet, thelogic 52 initializes the end of buffer indicator 67 (FIG. 3 ) to a null value, and sets thesequence indicator 68 based on the sequence that the packets are formed and transmitted from the transmittingunit 38. For example, assume that thepacketization logic 52 assigns each packet asequence indicator 68 that is incremented with respect to the preceding packet formed by thelogic 52. - After packetizing the graphical data retrieved from the
aforementioned buffer 46, thepacketization logic 52 transmits the packets to thenetwork 33 vianetwork interface 55. The packets are preferably transmitted to thenetwork 55 in the same sequence that they were formed such that each transmitted packet generally has asequence indicator 68 with a higher value as compared to thesequence indicators 68 of the packets transmitted before it. Thus, by analyzing thesequence indicators 68 of the transmitted packets, it is possible to determine the sequence that the packets were transmitted from the transmittingunit 38. - When the transmitted sequence of packets arrives at the receiving
unit 35, the packets are received by the socket 88 (FIG. 4 ). As shown bydecision block 312 and blocks 313 and 314 ofFIG. 8 , the receivelogic 92 performs a bulk read of thesocket 88 thereby storing at least a portion of the transmission sequence into one of thepre-allocated buffers 94. In this regard, the receivelogic 92 pulls abuffer pointer entry 99 from thebuffer pointer pool 98 and writes the data read from thesocket 88 during the bulk read to thebuffer 94 identified by the pointer 102 (FIG. 5 ) of the pulledentry 99. As shown byblock 314, the receivelogic 92 preferably continues with the bulk read until the foregoingbuffer 94 is full or until all of the data has been read from thesocket 88. Note that pulling theentry 99 from thepool 98 has the effect of disabling the receivelogic 92 from overwriting the data stored in the foregoingbuffer 94 until anentry 99 with thesame pointer 102 is later inserted into thebuffer pointer pool 98. - After performing the bulk read, the receive
logic 92 scans thebuffer 94 and identifies each packet within thebuffer 94, including the last complete packet stored in thebuffer 94, as shown byblock 317. While scanning thebuffer 94, the receivelogic 92 provides, to theflow control logic 112, thesequence indicator 68 of each packet in thebuffer 94. As will be described in more detail hereinbelow, theflow control logic 112 determines whether there are any data packets missing from the sequence of packets stored in thebuffer 94. - As shown by
block 318, the receivelogic 92 updates the end of buffer indicator 67 (FIG. 3 ) of the last complete data packet stored in thebuffer 94 such that thisindicator 67 points to the first memory address of thebuffer 94. Note that, by changing the value of theindicator 67 to a value other than the initialized value (i.e., the null value in the examples described above), theindicator 67 indicates that its data packet is the last complete packet of thebuffer 94 or, in other words, that the foregoing packet is not followed in thebuffer 94 by a complete data packet. - In
decision block 321, the receivelogic 92 determines whether the last packet stored in thebuffer 94 is an incomplete or partial packet. If so, the receivelogic 92 copies the data defining the partial packet into thenext buffer 94 to be used for storing the data from the next successive bulk read performed by the receivelogic 92. In this regard, inblock 324, the receivelogic 92 pulls, from thebuffer pointer pool 98, anentry 99, referred to hereafter as the “new entry 99.” The receivelogic 92 then writes the partial packet into the first memory address of thebuffer 94, referred to hereafter as the “new buffer 94,” identified by thenew entry 99, as shown byblock 327. Then, the receivelogic 92 inserts, into thequeue 122, thepointer entry 99 that points to the scanned buffer 94 (i.e., thepointer entry 99 previously described as being pulled from thepool 98 in block 313), as shown byblock 329. The receivelogic 92 then proceeds to block 314 and performs a bulk read of thesocket 88. - Note that the first set of data read during this bulk read corresponds to the remaining portion of the partial packet copied to the
new buffer 94 inblock 327. This first set of data is preferably written immediately following the partial packet such that the partial packet is transformed into a complete packet via the addition of the first set of data. The remainder of the data read from thesocket 88 may be stored in the following memory addresses of thenew buffer 94 until thenew buffer 94 is full or until thesocket 88 is empty. - If the receive
logic 92 determines, indecision block 321, that the last packet is not incomplete, then receivelogic 92skips steps block 332, the receive logic inserts, into thequeue 122, thepointer entry 99 that points to the scanned buffer 94 (i.e., thepointer entry 99 previously described as being pulled from thepool 98 in block 313). The receivelogic 92 returns to block 312 and repeats the aforedescribed process such that data read from thesocket 88, via another bulk read, is stored into adifferent buffer 94. - As described above, the receive
logic 92 transmits, to theflow control logic 112, thesequence indicators 68 of the packets stored in thebuffer 94 being scanned viablock 317. Based on this information, theflow control logic 112 determines whether there are any data packets missing from the sequence stored in the foregoingbuffer 94, as shown by decision blocks 352 and 354 ofFIG. 9 . If there is a missing sequence of data packets, theflow control logic 112 submits a retransmission request, as shown byblock 357. - The foregoing retransmission request is communicated to the transmitting unit 38 (
FIG. 1 ) and identifies the missing sequence of packets. In response, the transmittingunit 38 retransmits the missing sequence of packets. As described above, the retransmitted sequence of data packets preferably arrives at the retransmission socket 89, and theflow control logic 112 stores the retransmitted sequence to abuffer 94 that is temporarily dedicated to this sequence. - In this regard, upon detection of the retransmission sequence, the
flow control logic 112 pulls abuffer pointer entry 99 from thebuffer pointer pool 98 and writes the entire retransmitted sequence into thebuffer 94 identified by the pulledentry 99, as shown by decision blocks 362, 363 and 367. Inblock 372, theflow control logic 112 preferably adjusts the end of buffer indicator 67 (FIG. 3 ) of the last packet of the retransmitted sequence such that theindicator 67 points to the first address of the foregoingbuffer 94 thereby indicating that this packet is the last packet of thebuffer 94. Theflow control logic 112 then inserts, into thequeue 122, the pulledentry 99 that identifies thebuffer 94 storing the retransmitted sequence, as shown byblock 376. Before storing thisentry 99 into thequeue 122, theflow control logic 112 preferably inserts, into the entry's header 101 (FIG. 5 ), information indicating that theentry 99 points to the missing packet sequence. In this regard, the information may indicate the range ofsequence indicators 68 of the packets stored in thebuffer 94 identified by the foregoingentry 99. - As shown by
blocks FIG. 10 , thepacket delivery logic 134 checks thequeue 122 and pulls anentry 99 from thequeue 122 if such anentry 99 is available. Thepacket delivery logic 134 then scans thebuffer 94 identified by theentry 99 and determines whether there are any data packets missing from the packet sequence stored in the scannedbuffer 94, as shown byblocks packet delivery logic 134, as shown byblock 422, provides theentry 99 pulled from thequeue 122 viablock 408 to the rendering element 153 (FIG. 4 ). Therendering element 153 then renders the data stored in thebuffer 94 identified by the foregoingentry 99. Upon rendering such data, therendering element 153 returns theentry 99 to thebuffer pointer pool 98 thereby freeing the foregoingbuffer 94. - However, if the
packet delivery logic 134 detects that a sequence of data packets are missing from the foregoingbuffer 94 or, in other words, detects that the sequence of data packets in thebuffer 94 is incomplete, then thelogic 134 pulls anentry 99, referred to as “new entry 99,” from thepool 98 inblock 430 and constructs a complete packet sequence inblock 431. In this regard, thepacket delivery logic 134 locates and retrieves the missing packet sequence and combines this missing packet sequence with the incomplete packet sequence to form a complete packet sequence. Thelogic 134 then stores the complete packet sequence into thebuffer 94, referred to as the “new buffer 94,” that is identified by thenew entry 99. - As an example, assume that the incomplete packet sequence has
indicators 68 ranging consecutively from one-hundred (100) to one-hundred-fifty (150) and from three-hundred (300) to four-hundred (400). In such an example, thebuffer 94 storing this sequence is missing the packets havingsequence indicators 68 ranging from 151 through 299. - In such an example, the
flow control logic 112 requests retransmission of the missing packet sequence (i.e., the packets havingsequence indicators 68 ranging consecutively from one-hundred-fifty-one (151) to two-hundred-ninety-nine (299)) inblock 357 ofFIG. 9 . Theflow control logic 112 also stores the missing packet sequence to one of thebuffers 94 inblock 367 and inserts, into thequeue 122, anentry 99 identifying thisbuffer 94. Moreover, in implementingblock 431 ofFIG. 10 , thepacket delivery logic 134 locates the forgoingentry 99 based on the entry'sheader 101 and then pulls thisentry 99 from thequeue 122. Thepacket delivery logic 134 then retrieves the missing packet sequence from thebuffer 94 identified by the foregoingentry 99 and writes these packets, along with the incomplete packet sequence stored in thebuffer 94 scanned viablock 412, into thenew buffer 94. Therefore, thenew buffer 94 stores the complete packet sequence (i.e., a packet sequence having eachindicator 68 ranging consecutively from one-hundred (100) to four-hundred (400)). - In
block 436, thepacket delivery logic 134 returns the twoentries 99 that identify thebuffers 94 storing the missing packet sequence and the incomplete packet sequence. Further, inblock 439, thepacket delivery logic 134 provides the remaining entry 99 (i.e., thenew entry 99 that points to thenew buffer 94, which is storing the complete packet sequence) to therendering element 153. Therendering element 153 then renders the graphical data stored in thenew buffer 94 and returns thenew entry 99 to bufferpointer pool 98 thereby freeing thenew buffer 94. Thus, thepacket delivery logic 134 ensures that eachentry 99 provided to therendering element 153 points to abuffer 94 storing a complete packet sequence.
Claims (25)
1. A system for buffering data from a network, comprising:
a network socket;
a plurality of pre-allocated buffers;
a buffer pointer pool having a plurality of entries respectively pointing to the buffers;
receive logic configured to pull an entry from the pool and to perform a bulk read of the network socket, the entry pointing to one of the buffers, the receive logic further configured to store data from the bulk read to the one buffer based on the entry; and
packet delivery logic configured to read, based on the entry, the one buffer and to locate a missing packet sequence in response to a determination, by the packet delivery logic, that the one buffer is storing an incomplete packet sequence, the packet delivery logic further configured to form a complete packet sequence based on the incomplete packet sequence and the missing packet sequence.
2. The system of claim 1 , wherein each of the buffers is pre-allocated.
3. The system of claim 1 , wherein the receive logic is configured to insert the entry into a queue, and wherein the packet delivery logic is configured to pull the entry from the queue.
4. The system of claim 3 , wherein the packet delivery logic is configured to search the queue, in response to the determination, for an entry pointing to at least one data packet within the missing packet sequence.
5. The system of claim 1 , wherein the receive logic is configured to run on a first operating system thread, and wherein the packet delivery logic is configured to run on a second operating system thread.
6. The system of claim 1 , wherein the receive logic is configured to perform a scan of the one buffer and to identify, based on the scan, a partial packet stored in the one buffer, the receive logic further configured to write the partial packet to another of the buffers.
7. The system of claim 1 , wherein the receive logic is configured to perform a scan of the one buffer and to identify, based on the scan, a last complete packet of the one buffer, the receive logic further configured to store, in the one buffer, data indicative of the last complete packet, wherein the packet delivery logic is configured to identify the incomplete packet sequence based on the data that is indicative of the last complete packet.
8. The system of claim 7 , wherein the data indicative of the last complete packet comprises a pointer pointing to a starting address of the one buffer.
9. The system of claim 1 , wherein the missing packet sequence comprises at least two data packets consecutively transmitted from a remote transmitting unit.
10. The system of claim 1 , wherein the packet delivery logic is configured to form the complete packet sequence by inserting data packets of the missing packet sequence between data packets of the incomplete packet sequence.
11. The system of claim 1 , wherein the packet delivery logic is configured to push the entry to the pool once the data has been read from the one buffer thereby freeing the one buffer for storing other data.
12. The system of claim 1 , wherein the receive logic is configured to store the missing packet sequence to one of the buffers, and wherein the packet delivery logic is configured to search the entries in response to the determination to locate an entry pointing to the one buffer storing the missing packet sequence.
13. The system of claim 12 , wherein the packet delivery logic is configured to retrieve, based on the one entry, the missing packet sequence and to insert the retrieved missing packet sequence between data packets of the incomplete packet sequence.
14. A method for buffering data from a network, comprising:
storing, into a buffer pointer pool, entries respectively pointing to one of a plurality of buffers;
pulling an entry from the pool, the entry pointing to one of the buffers;
storing data, from a bulk read of a network socket, to the one buffer based on the entry;
inserting the entry into a queue;
reading the one buffer based on the inserted entry;
determining, based on the reading, that the one buffer is storing an incomplete packet sequence, the incomplete packet sequence comprising at least two non-sequential data packets; and
forming, in response to the determining, a complete packet sequence based on the incomplete packet sequence.
15. The method of claim 14 , further comprising pre-allocating each of the buffers.
16. The method of claim 14 , wherein the storing to the one buffer is performed by logic running on a first operating system thread, and wherein the determining is performed by logic running on a second operating system thread.
17. The method of claim 14 , further comprising:
scanning the one buffer;
identifying a partial packet based on the scanning; and
writing the partial packet to another of the buffers.
18. The method of claim 14 , further comprising:
identifying a last complete packet of the one buffer; and
storing, in the one buffer, data indicative of the last complete packet.
19. The method of claim 18 , wherein the data indicative of the last complete packet comprises a pointer pointing to a starting address of the one buffer.
20. The method of claim 14 , further comprising freeing the one buffer for storing other data, wherein the freeing comprises pushing the entry to the pool.
21. The method of claim 14 , wherein the forming comprises locating a sequence of data packets missing from the incomplete packet sequence.
22. The method of claim 21 , wherein the forming comprises inserting the sequence of data packets between the at least two non-sequential data packets.
23. The method of claim 21 , wherein the forming comprises inserting the sequence of missing data packets between the at least two non-sequential data packets.
24. The method of claim 21 , wherein the locating comprises searching the queue for an entry pointing to at least one of the data packets within the sequence of missing data packets.
25. The method of claim 24 , wherein the searching is performed in response to the determination.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/176,971 US20080279208A1 (en) | 2003-02-08 | 2008-07-21 | System and method for buffering data received from a network |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/361,742 US7430623B2 (en) | 2003-02-08 | 2003-02-08 | System and method for buffering data received from a network |
US12/176,971 US20080279208A1 (en) | 2003-02-08 | 2008-07-21 | System and method for buffering data received from a network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/361,742 Division US7430623B2 (en) | 2003-02-08 | 2003-02-08 | System and method for buffering data received from a network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080279208A1 true US20080279208A1 (en) | 2008-11-13 |
Family
ID=32824292
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/361,742 Expired - Fee Related US7430623B2 (en) | 2003-02-08 | 2003-02-08 | System and method for buffering data received from a network |
US12/176,971 Abandoned US20080279208A1 (en) | 2003-02-08 | 2008-07-21 | System and method for buffering data received from a network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/361,742 Expired - Fee Related US7430623B2 (en) | 2003-02-08 | 2003-02-08 | System and method for buffering data received from a network |
Country Status (1)
Country | Link |
---|---|
US (2) | US7430623B2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080192775A1 (en) * | 2007-02-13 | 2008-08-14 | Seiko Epson Corporation | Transmitting and receiving system, transmitting apparatus, and receiving apparatus |
US20110219195A1 (en) * | 2010-03-02 | 2011-09-08 | Adi Habusha | Pre-fetching of data packets |
CN102193874A (en) * | 2010-03-18 | 2011-09-21 | 马维尔国际贸易有限公司 | Buffer manager and method for managing memory |
US20110228674A1 (en) * | 2010-03-18 | 2011-09-22 | Alon Pais | Packet processing optimization |
US9069489B1 (en) | 2010-03-29 | 2015-06-30 | Marvell Israel (M.I.S.L) Ltd. | Dynamic random access memory front end |
US9098203B1 (en) | 2011-03-01 | 2015-08-04 | Marvell Israel (M.I.S.L) Ltd. | Multi-input memory command prioritization |
US20170200466A1 (en) * | 2012-02-15 | 2017-07-13 | Microsoft Technology Licensing, Llc | Mix buffers and command queues for audio blocks |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7436535B2 (en) * | 2003-10-24 | 2008-10-14 | Microsoft Corporation | Real-time inking |
US8060743B2 (en) * | 2003-11-14 | 2011-11-15 | Certicom Corp. | Cryptographic method and apparatus |
US20060047849A1 (en) * | 2004-06-30 | 2006-03-02 | Mukherjee Shubhendu S | Apparatus and method for packet coalescing within interconnection network routers |
US7783823B2 (en) * | 2007-07-31 | 2010-08-24 | Hewlett-Packard Development Company, L.P. | Hardware device data buffer |
FR2925190B1 (en) * | 2007-12-18 | 2009-11-20 | Alcatel Lucent | METHOD AND DEVICE FOR COMMUNICATION BETWEEN MULTIPLE CONNECTION INTERFACES |
US9178815B2 (en) | 2013-03-05 | 2015-11-03 | Intel Corporation | NIC flow switching |
KR101487859B1 (en) | 2014-01-15 | 2015-02-02 | 주식회사 이디엄 | Method for Collecting UDP Packet When Java Program Is Being Executed |
US9851941B2 (en) | 2014-06-18 | 2017-12-26 | Nxp Usa, Inc. | Method and apparatus for handling incoming data frames |
US10516710B2 (en) | 2017-02-12 | 2019-12-24 | Mellanox Technologies, Ltd. | Direct packet placement |
US10210125B2 (en) * | 2017-03-16 | 2019-02-19 | Mellanox Technologies, Ltd. | Receive queue with stride-based data scattering |
US11252464B2 (en) | 2017-06-14 | 2022-02-15 | Mellanox Technologies, Ltd. | Regrouping of video data in host memory |
US10367750B2 (en) | 2017-06-15 | 2019-07-30 | Mellanox Technologies, Ltd. | Transmission and reception of raw video using scalable frame rate |
Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4475192A (en) * | 1982-02-16 | 1984-10-02 | At&T Bell Laboratories | Data packet flow control scheme for switching networks |
US4933932A (en) * | 1987-12-24 | 1990-06-12 | Etat Francais represente par le Ministre des Postes et Telecommunications et de l'Espace (Centre National d'Etudes des Telecommunications) | Buffer queue write pointer control circuit notably for self-channelling packet time-division switching system |
US5016248A (en) * | 1988-10-27 | 1991-05-14 | Kabushiki Kaisha Toshiba | Buffer memory device for packet data and method of controlling the device |
US5291482A (en) * | 1992-07-24 | 1994-03-01 | At&T Bell Laboratories | High bandwidth packet switch |
US5303302A (en) * | 1992-06-18 | 1994-04-12 | Digital Equipment Corporation | Network packet receiver with buffer logic for reassembling interleaved data packets |
US5396490A (en) * | 1992-03-23 | 1995-03-07 | Motorola, Inc. | Packet reassembly method and apparatus |
US5610914A (en) * | 1994-05-24 | 1997-03-11 | Nec Corporation | Shared buffer memory switch for an ATM switching system and its broadcasting control method |
US5701427A (en) * | 1989-09-19 | 1997-12-23 | Digital Equipment Corp. | Information transfer arrangement for distributed computer system |
US5732082A (en) * | 1995-08-11 | 1998-03-24 | International Business Machines Corp. | System and method for multi-frame received queuing with sorting in an asynchronous transfer mode (ATM) system |
US5802058A (en) * | 1996-06-03 | 1998-09-01 | Lucent Technologies Inc. | Network-independent connection management |
US6128295A (en) * | 1997-07-11 | 2000-10-03 | Telefonaktiebolaget Lm Ericsson | Buffering of point-to-point and/or point-to-multipoint ATM cells |
US6212165B1 (en) * | 1998-03-24 | 2001-04-03 | 3Com Corporation | Apparatus for and method of allocating a shared resource among multiple ports |
US6266701B1 (en) * | 1997-07-02 | 2001-07-24 | Sitara Networks, Inc. | Apparatus and method for improving throughput on a data network |
US6314100B1 (en) * | 1998-03-26 | 2001-11-06 | Emulex Corporation | Method of validation and host buffer allocation for unmapped fibre channel frames |
US6400695B1 (en) * | 1998-05-22 | 2002-06-04 | Lucent Technologies Inc. | Methods and apparatus for retransmission based access priority in a communications system |
US6445717B1 (en) * | 1998-05-01 | 2002-09-03 | Niwot Networks, Inc. | System for recovering lost information in a data stream |
US6539431B1 (en) * | 1998-11-12 | 2003-03-25 | Cisco Technology, Inc. | Support IP pool-based configuration |
US20030235202A1 (en) * | 2002-06-19 | 2003-12-25 | Van Der Zee Thomas Martinus | Methods of transmitting data packets without exceeding a maximum queue time period and related devices |
US7149220B2 (en) * | 2002-04-25 | 2006-12-12 | International Business Machines Corporation | System, method, and product for managing data transfers in a network |
US7542472B1 (en) * | 1999-11-17 | 2009-06-02 | Nokia Corporation | Data transmission |
-
2003
- 2003-02-08 US US10/361,742 patent/US7430623B2/en not_active Expired - Fee Related
-
2008
- 2008-07-21 US US12/176,971 patent/US20080279208A1/en not_active Abandoned
Patent Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4475192A (en) * | 1982-02-16 | 1984-10-02 | At&T Bell Laboratories | Data packet flow control scheme for switching networks |
US4933932A (en) * | 1987-12-24 | 1990-06-12 | Etat Francais represente par le Ministre des Postes et Telecommunications et de l'Espace (Centre National d'Etudes des Telecommunications) | Buffer queue write pointer control circuit notably for self-channelling packet time-division switching system |
US5016248A (en) * | 1988-10-27 | 1991-05-14 | Kabushiki Kaisha Toshiba | Buffer memory device for packet data and method of controlling the device |
US5701427A (en) * | 1989-09-19 | 1997-12-23 | Digital Equipment Corp. | Information transfer arrangement for distributed computer system |
US5396490A (en) * | 1992-03-23 | 1995-03-07 | Motorola, Inc. | Packet reassembly method and apparatus |
US5303302A (en) * | 1992-06-18 | 1994-04-12 | Digital Equipment Corporation | Network packet receiver with buffer logic for reassembling interleaved data packets |
US5291482A (en) * | 1992-07-24 | 1994-03-01 | At&T Bell Laboratories | High bandwidth packet switch |
US5610914A (en) * | 1994-05-24 | 1997-03-11 | Nec Corporation | Shared buffer memory switch for an ATM switching system and its broadcasting control method |
US5732082A (en) * | 1995-08-11 | 1998-03-24 | International Business Machines Corp. | System and method for multi-frame received queuing with sorting in an asynchronous transfer mode (ATM) system |
US5802058A (en) * | 1996-06-03 | 1998-09-01 | Lucent Technologies Inc. | Network-independent connection management |
US6266701B1 (en) * | 1997-07-02 | 2001-07-24 | Sitara Networks, Inc. | Apparatus and method for improving throughput on a data network |
US6128295A (en) * | 1997-07-11 | 2000-10-03 | Telefonaktiebolaget Lm Ericsson | Buffering of point-to-point and/or point-to-multipoint ATM cells |
US6212165B1 (en) * | 1998-03-24 | 2001-04-03 | 3Com Corporation | Apparatus for and method of allocating a shared resource among multiple ports |
US6314100B1 (en) * | 1998-03-26 | 2001-11-06 | Emulex Corporation | Method of validation and host buffer allocation for unmapped fibre channel frames |
US6445717B1 (en) * | 1998-05-01 | 2002-09-03 | Niwot Networks, Inc. | System for recovering lost information in a data stream |
US6400695B1 (en) * | 1998-05-22 | 2002-06-04 | Lucent Technologies Inc. | Methods and apparatus for retransmission based access priority in a communications system |
US6539431B1 (en) * | 1998-11-12 | 2003-03-25 | Cisco Technology, Inc. | Support IP pool-based configuration |
US7542472B1 (en) * | 1999-11-17 | 2009-06-02 | Nokia Corporation | Data transmission |
US7149220B2 (en) * | 2002-04-25 | 2006-12-12 | International Business Machines Corporation | System, method, and product for managing data transfers in a network |
US20030235202A1 (en) * | 2002-06-19 | 2003-12-25 | Van Der Zee Thomas Martinus | Methods of transmitting data packets without exceeding a maximum queue time period and related devices |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080192775A1 (en) * | 2007-02-13 | 2008-08-14 | Seiko Epson Corporation | Transmitting and receiving system, transmitting apparatus, and receiving apparatus |
US7769014B2 (en) * | 2007-02-13 | 2010-08-03 | Seiko Epson Corporation | Transmitting and receiving system, transmitting apparatus, and receiving apparatus |
US20110219195A1 (en) * | 2010-03-02 | 2011-09-08 | Adi Habusha | Pre-fetching of data packets |
US9037810B2 (en) | 2010-03-02 | 2015-05-19 | Marvell Israel (M.I.S.L.) Ltd. | Pre-fetching of data packets |
US8327047B2 (en) * | 2010-03-18 | 2012-12-04 | Marvell World Trade Ltd. | Buffer manager and methods for managing memory |
US20110296063A1 (en) * | 2010-03-18 | 2011-12-01 | Alon Pais | Buffer manager and methods for managing memory |
US20110228674A1 (en) * | 2010-03-18 | 2011-09-22 | Alon Pais | Packet processing optimization |
CN102193874A (en) * | 2010-03-18 | 2011-09-21 | 马维尔国际贸易有限公司 | Buffer manager and method for managing memory |
US9769081B2 (en) * | 2010-03-18 | 2017-09-19 | Marvell World Trade Ltd. | Buffer manager and methods for managing memory |
US9069489B1 (en) | 2010-03-29 | 2015-06-30 | Marvell Israel (M.I.S.L) Ltd. | Dynamic random access memory front end |
US9098203B1 (en) | 2011-03-01 | 2015-08-04 | Marvell Israel (M.I.S.L) Ltd. | Multi-input memory command prioritization |
US20170200466A1 (en) * | 2012-02-15 | 2017-07-13 | Microsoft Technology Licensing, Llc | Mix buffers and command queues for audio blocks |
US10157625B2 (en) * | 2012-02-15 | 2018-12-18 | Microsoft Technology Licensing, Llc | Mix buffers and command queues for audio blocks |
Also Published As
Publication number | Publication date |
---|---|
US20040156379A1 (en) | 2004-08-12 |
US7430623B2 (en) | 2008-09-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20080279208A1 (en) | System and method for buffering data received from a network | |
US7908335B1 (en) | Methods and apparatus for bridging a USB connection | |
US6615383B1 (en) | System and method for message transmission between network nodes connected by parallel links | |
US11163850B2 (en) | System, method and computer program product for data transfer management | |
US7233573B2 (en) | Apparatus and method for receiving data from a network | |
TWI332150B (en) | Processing data for a tcp connection using an offload unit | |
EP0753817A1 (en) | Method and apparatus for data communication | |
US7561573B2 (en) | Network adaptor, communication system and communication method | |
JP2002523824A (en) | Network printing system | |
US9071525B2 (en) | Data receiving apparatus, data receiving method, and program storage medium | |
US8928681B1 (en) | Coalescing to avoid read-modify-write during compressed data operations | |
JPH11143845A (en) | System and method for message transmission between network nodes | |
US20050116958A1 (en) | System and method utilizing multiple processes to render graphical data | |
US8576861B2 (en) | Method and apparatus for processing packets | |
US6304553B1 (en) | Method and apparatus for processing data packets | |
US7319670B2 (en) | Apparatus and method for transmitting data to a network based on retransmission requests | |
US8798085B2 (en) | Techniques to process network protocol units | |
US20030110233A1 (en) | Reflective memory system and method capable of dynamically sizing data packets | |
US7817572B2 (en) | Communications apparatus and communication method | |
US7373408B2 (en) | Network communication apparatus and method | |
CN114125081B (en) | Method and device for processing received data and storage medium | |
US8005971B2 (en) | Apparatus for communicating with a network | |
US7450599B2 (en) | Apparatus and method for communicating with a network | |
US6389478B1 (en) | Efficient non-contiguous I/O vector and strided data transfer in one sided communication on multiprocessor computers | |
US7298755B2 (en) | Apparatus and method for communicating with a network and for monitoring operational performance of the apparatus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |