Re: send & MSG_DONTWAIT

David Schwartz <davids@xxxxxxxxxxxxx> writes:
On Jul 15, 9:23 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
The sending application has zero control regarding specifics of the
TCP transport and neither has the receiving application.

Right. That's why an "all or nothing" non-blocking send doesn't exist.
Giving applications that kind of control would allow them to break the
TCP protocol.

This call does not exist because the particulars of the transport are
handled by the transport protocol.

If the receiver wants to limit the window to one byte, such that the
sender can only send one byte at a time, there will be no
deadlock. There will only be a deadlock if the sender also refuses
to send a single byte.

Interactions among sending and receiving TCP happen inside the
TCP-implementations used on each end. But the question was about an
application using an existing TCP-implementation. If the sending
application wants to be able to 'send complete frames', it just needs
something like an acknowledgement from the receiving application that
the last 'complete frame' has been received and then, it can queue the
next 'complete frame', waiting for the next application ack from
remote before queueing any more data to send. That's stupid for bulk
data transfers, but completely possible.

It still can't send a complete frame with a non-blocking call.
If a frame is 348 bytes, when it calls 'write' or 'send', it's always
possible that the stack will take 124 bytes.

No, this is not 'always possible'. The buffer size is both know and
configurable and the state of the buffer is known by virtue of the
state of the application protocol, ie when the remote peer has
communicated that it has received all data sent so far, the local
buffer is necessarily empty.

More precisely, this is absolutely never possible, given the context
of the situation.
.

Relevant Pages

  • Re: send & MSG_DONTWAIT
    ... TCP transport and neither has the receiving application. ... That's why an "all or nothing" non-blocking send doesn't exist. ... the last 'complete frame' has been received and then, ...
    (comp.unix.programmer)
  • SetRThreshold does not works as expected
    ... My application is receiving binary data from a device connected to ... uart and have to analyze it byte to byte to identify frames. ... Example: The device send me this frame: A2 03 A5 ... time OnCommEvent fires up: ...
    (microsoft.public.vc.mfc)
  • Re: send & MSG_DONTWAIT
    ... The application protocol can't control the receive window. ... That's why TCP permits the receiver to decide never to accept a ... "complete frame" if it doesn't want to. ... TCP transport and neither has the receiving application. ...
    (comp.unix.programmer)
  • [patch] r8169: fix crash when large packets are received
    ... Michael Tokarev reported receiving a large packet could crash ... When a frame larger than what was allocated by driver is received, ... Fix is to tell to NIC what is the maximum size a frame can be. ...
    (Linux-Kernel)
  • Re: SetRThreshold does not works as expected
    ... My application is receiving binary data from a device connected to ... The Frames have different lengths, so I Set SetRThreshold to 1, to ... Example: The device send me this frame: A2 03 A5 ... time OnCommEvent fires up: ...
    (microsoft.public.vc.mfc)