184.108.40.206 Use of Push: RFC-793 Section 2.8 When an application issues a series of SEND calls without setting the PUSH flag, the TCP MAY aggregate the data internally without sending it. Similarly, when a series of segments is received without the PUSH bit, a TCP MAY queue the data internally without passing it to the receiving application. The PUSH bit is not a record marker and is independent of segment boundaries. The transmitter SHOULD collapse successive PUSH bits when it packetizes data, to send the largest possible segment. A TCP MAY implement PUSH flags on SEND calls. If PUSH flags are not implemented, then the sending TCP: (1) must not buffer data indefinitely, and (2) MUST set the PUSH bit in the last buffered segment (i.e., when there is no more queued data to be sent). The discussion in RFC-793 on pages 48, 50, and 74 erroneously implies that a received PUSH flag must be passed to the application layer. Passing a received PUSH flag to the application layer is now OPTIONAL. An application program is logically required to set the PUSH flag in a SEND call whenever it needs to force delivery of the data to avoid a communication deadlock. However, a TCP SHOULD send a maximum-sized segment whenever possible, to improve performance (see Section 220.127.116.11). DISCUSSION: When the PUSH flag is not implemented on SEND calls, i.e., when the application/TCP interface uses a pure streaming model, responsibility for aggregating any tiny data fragments to form reasonable sized segments is partially borne by the application layer. Generally, an interactive application protocol must set the PUSH flag at least in the last SEND call in each command or response sequence. A bulk transfer protocol like FTP should set the PUSH flag on the last segment of a file or when necessary to prevent buffer deadlock. At the receiver, the PUSH bit forces buffered data to be delivered to the application (even if less than a full buffer has been received). Conversely, the lack of a PUSH bit can be used to avoid unnecessary wakeup calls to the application process; this can be an important performance optimization for large timesharing hosts. Passing the PUSH bit to the receiving application allows an analogous optimization within the application.
A client-server pair is going to transfer 4096 bytes between them on Ethernet. The client application executes a send() for 4096 bytes. Windows NT TCP/IP breaks the 4096 bytes into three Ethernet packets: 1460 bytes, no PUSH 1460 bytes, no PUSH 1176 bytes, PUSH is set At the same time, the server executes recv(), for 8192 bytes. When the first packet arrives, TCP puts the data into the user buffer. The same thing happens for the second packet since PUSH is still not set. However, when the third packet arrives, TCP completes the recv() because PUSH was set.
ID d'article : 123749 - Dernière mise à jour : 02/27/2014 10:17:15 - Révision : 2.1