Prev: processor time
Next: chroot() and popen() won't get along
From: Bill Cunningham on 15 Apr 2010 08:20
victor Yankee wrote:
> Would someone be able to point me in the right direction ?

[snip]

> Do you know if there is any other method that we could use to do this
> or do we need to use RAW sockets and or modify the kernel TCP/IP
> stack ?

In my humble opinion possibly you might want to look at UDP and sendto()
and recvfrom() that goes usually with SOCK_DGRAM.

http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html

Bill


From: David Schwartz on 15 Apr 2010 16:04
On Apr 14, 11:01 pm, victor Yankee <vyank...(a)gmail.com> wrote:

> We are looking at implementing a socket server using TCP/IP socket
> streams on Solaris 10.  One of the requirements is that we need to
> only send TCP ACK messages once our application has flushed the
> payload to non-volatile memory.

This is a fundamentally broken requirement. Whatever underlying real
requirement this requirement was intended to meet should be met some
other way.

> We were looking at using the MSG_PEEK flag to read the data of the
> socket however this call does not stop the TCP stack from acking more
> packets until our RCVBUF is full. This means that if our application
> dies we could be loosing data that is in our RCVBUF.

That is, fundamentally, the nature of TCP. You cannot change it simply
by requiring it to be otherwise.

> Do you know if there is any other method that we could use to do this
> or do we need to use RAW sockets and or modify the kernel TCP/IP
> stack ?

I wouldn't put effort into meeting a nonsensical requirement. One
could only get into a situation where this seemed like it should be a
requirement by making fundamental mistakes elsewhere. Those mistakes
should be fixed.

Fundamentally, a TCP ACK's sole purpose is to provide TCP flow
control. If the other end takes some other semantic meaning from it,
that device is simply broken. You cannot fix it from the other side.

Also, a critical misunderstanding:
"We are expected to only ack the packets once they have been cached to
non-
volatile memory."
This may just be sloppy writing, but one *never* ACKs a packet. In
TCP, ACKs simply acknowledge the receipt of things that occupy
sequence space, such as byte ranges of data.

DS
First  |  Prev  | 
Pages: 1 2
Prev: processor time
Next: chroot() and popen() won't get along