Re: send & MSG_DONTWAIT

David Schwartz <davids@xxxxxxxxxxxxx> writes:
On Jul 15, 1:29 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
David Schwartz <dav...@xxxxxxxxxxxxx> writes:
On Jul 14, 2:45 am, Kyku <kwrza...@xxxxxxxxx> wrote:
The only reason is that I wouldn't like to put incomplete frames into
send buffer.

And suppose the receiver doesn't like to get complete frames in its
receive buffer.

That's a problem of the application protocol which in use and the
solution is "don't do this".

The application protocol can't control the receive window.

So what? Who is going to send what when is entirely a matter of the
application protocol used by a pair of communicating applications. TCP
is just concerned with transporting whatever is supposed to be sent
reliably to the remote peer.

For obvious reason, an application
protocol which has been 'designed to deadlock' will actually cause
application deadlocks.

Right. That's why TCP permits the receiver to decide never to accept a
"complete frame" if it doesn't want to. The sender, therefore, cannot
decide to only send "complete frames" because the receiver may never
allow it to send a complete frame.

The sending application has zero control regarding specifics of the
TCP transport and neither has the receiving application.

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.

This is not (always) going to achieve what the OP probably intendend
(send each 'complete frame' as a single TCP segment), but since he had
been writing about 'retransmitting complete frames' in order to cope
with physical layer unreliability, chances are that he was just
confused, anyway. There is no reason to confuse him even more by
passionate layer-hopping.
.

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)
  • Re: messaging protocol - how about this as a design
    ... I am using tcp and am designing a protocol for sending and receiving ... Your design is very naive. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Hardware firewall blocking L2TP/IPSec VPN
    ... Protocol Info ... Frame 162 ... [Coloring Rule Name: UDP] ... Next payload: Security Association ...
    (microsoft.public.isa.vpn)
  • Re: atl1e: TSO is broken
    ... TCP Segmentation Offload result in broken IPv4-packets sent out ... Turn off TSO. ... TCP Segmentation Offload is default enabled in the atl1e ... Capture of 146-byte Ethernet frame with bad IP-header: ...
    (Linux-Kernel)
  • atl1e: TSO is broken
    ... TCP Segmentation Offload result in broken IPv4-packets sent out ... Turn off TSO. ... TCP Segmentation Offload is default enabled in the atl1e ... Capture of 146-byte Ethernet frame with bad IP-header: ...
    (Linux-Kernel)