🚀 go-pugleaf

Josh Arnold wrote:

>My new problem is that when ACK'ing back to the server after receiving the
>data, the ACK is taking around 200ms.  Completely unacceptable for the
>application and I'm obviously doing something wrong.

I'll repost my repost from 1/17/2006


See my message from 5/4/2005
50th71db9qmpnog2gldkeqvsfv112h3ano@4ax.com

Subject: Re: sendto to same destination more times after eachother
fails.?

TCP buffers data so the data-to-packetheader ratio is sane. When
sending a single integer, the packet is several times the size of the
data, quite wastefull, so by default, TCP holds onto the data for a
period of time, hoping more data will be sent.
If you don't want to wait for the timeout, you need to tell TCP not to
wait.

Look into this WinSock API command, and parameters..

setsockopt(ClientOutSocket,IPPROTO_TCP,TCP_NODELAY,(char*)&t,sizeof(t));

Bob-

Thanks!  I knew I was missing something.  Is t the timeout? What should
thins be initialized as?

-Josh
"Bob Gonder" <notbg@notmindspring.invalid> wrote in message
news:0hvpi29knbm09uif8ncifnmcuihfr6ttsa@4ax.com...
> Josh Arnold wrote:
>
> >My new problem is that when ACK'ing back to the server after receiving
the
> >data, the ACK is taking around 200ms.  Completely unacceptable for the
> >application and I'm obviously doing something wrong.
>
> I'll repost my repost from 1/17/2006
>
>
> See my message from 5/4/2005
> 50th71db9qmpnog2gldkeqvsfv112h3ano@4ax.com
>
> Subject: Re: sendto to same destination more times after eachother
> fails.?
>
> TCP buffers data so the data-to-packetheader ratio is sane. When
> sending a single integer, the packet is several times the size of the
> data, quite wastefull, so by default, TCP holds onto the data for a
> period of time, hoping more data will be sent.
> If you don't want to wait for the timeout, you need to tell TCP not to
> wait.
>
> Look into this WinSock API command, and parameters..
>
> setsockopt(ClientOutSocket,IPPROTO_TCP,TCP_NODELAY,(char*)&t,sizeof(t));
>
>
>

Josh Arnold wrote:
>
> Thanks!  I knew I was missing something.  Is t the timeout?
> What should thins be initialized as?

The last two parameters are optval and optlen.  IPPROTO_TCP is the option 
level, TCP_NODELAY is the option, and then you set what you want to do with 
that option.  In this case you want to turn the TCP_NODELAY option on, so 
you set it to true.  The following is what I have:


   BOOL enabled = TRUE;

   setsockopt((SOCKET)ClientSocket1->Socket->SocketHandle, IPPROTO_TCP,
                     TCP_NODELAY, (char*)&enabled, sizeof(BOOL));
   ClientSocket1->Open();

Also,

How do I get back a SOCKET type from the TTcpClient socket I am using in my
app?

Is this possible, everything I have tried so far does not work.

Tried
SOCKET s = client->Socket->SocketHandle;

Thanks,
Josh


"Bob Gonder" <notbg@notmindspring.invalid> wrote in message
news:0hvpi29knbm09uif8ncifnmcuihfr6ttsa@4ax.com...
> Josh Arnold wrote:
>
> >My new problem is that when ACK'ing back to the server after receiving
the
> >data, the ACK is taking around 200ms.  Completely unacceptable for the
> >application and I'm obviously doing something wrong.
>
> I'll repost my repost from 1/17/2006
>
>
> See my message from 5/4/2005
> 50th71db9qmpnog2gldkeqvsfv112h3ano@4ax.com
>
> Subject: Re: sendto to same destination more times after eachother
> fails.?
>
> TCP buffers data so the data-to-packetheader ratio is sane. When
> sending a single integer, the packet is several times the size of the
> data, quite wastefull, so by default, TCP holds onto the data for a
> period of time, hoping more data will be sent.
> If you don't want to wait for the timeout, you need to tell TCP not to
> wait.
>
> Look into this WinSock API command, and parameters..
>
> setsockopt(ClientOutSocket,IPPROTO_TCP,TCP_NODELAY,(char*)&t,sizeof(t));
>
>
>

Josh Arnold wrote:

>How do I get back a SOCKET type from the TTcpClient socket I am using in my
>Tried
>SOCKET s = client->Socket->SocketHandle;

Yet another repost, this time from Remy:
(I knew he had posted this, but couldn't find it the first time)

From: "Remy Lebeau \(TeamB\)" 
Newsgroups: borland.public.cppbuilder.internet.socket
Subject: Re: TServerSocket sends a unwanted acknowlege
Date: Wed, 21 Sep 2005 09:52:31 -0700
Message-ID: <43318fa3@newsgroups.borland.com>

> How and where to set the TCP_NODELAY option.
>
> Is the OnClientConnect event the right place?

That is fine.

<snip>

You need to use its SocketHandle property instead:

    setsockopt((SOCKET)Socket->SocketHandle, IPPROTO_TCP, TCP_NODELAY,
&fl,
sizeof(fl));


Gambit

Bob Gonder wrote
>
> From: "Remy Lebeau \(TeamB\)"
> Newsgroups: borland.public.cppbuilder.internet.socket
> Subject: Re: TServerSocket sends a unwanted acknowlege
> Date: Wed, 21 Sep 2005 09:52:31 -0700
> Message-ID: <43318fa3@newsgroups.borland.com>
>

> You need to use its SocketHandle property instead:
>
>    setsockopt((SOCKET)Socket->SocketHandle, IPPROTO_TCP, TCP_NODELAY,
> &fl, sizeof(fl));

That example was for a TServerSocket, and my example earlier was with a
TClientSocket.  I would assume that with a TTcpClient the equivalent
would probably be TcpClient1->Handle, but I haven't worked with that
component before, so I'm not positive.

OK,

I have tried the exact code posted already.  (I goofed an forgot that I am 
using TClientSocket and not TTcpClient).

However, if you actually look at the return value of setsockopt.  The code 
from the last post returns a -1 when I run it. It should be zero if 
everything is OK.
-Josh


"Lesley Anne" <mspfila-ng@yahoo.com> wrote in message 
news:452d5df9@newsgroups.borland.com...
> Bob Gonder wrote
>>
>> From: "Remy Lebeau \(TeamB\)"
>> Newsgroups: borland.public.cppbuilder.internet.socket
>> Subject: Re: TServerSocket sends a unwanted acknowlege
>> Date: Wed, 21 Sep 2005 09:52:31 -0700
>> Message-ID: <43318fa3@newsgroups.borland.com>
>>
>
>> You need to use its SocketHandle property instead:
>>
>>    setsockopt((SOCKET)Socket->SocketHandle, IPPROTO_TCP, TCP_NODELAY,
>> &fl, sizeof(fl));
>
> That example was for a TServerSocket, and my example earlier was with a
> TClientSocket.  I would assume that with a TTcpClient the equivalent
> would probably be TcpClient1->Handle, but I haven't worked with that
> component before, so I'm not positive.
>
> 

Josh Arnold wrote:

>However, if you actually look at the return value of setsockopt.  The code 
>from the last post returns a -1 when I run it. It should be zero if 
>everything is OK.

You should always check WSAGetLastError() whenever you get a socket
error to find out why.
The reason is often not what you think (esspecially in new code).

I think, if you followed Lesley's code, it would be wrong.
I think you need to Open() first, so you have a valid socket to set
the  option on.


This is the sequence my code uses:
	ClientSocket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
	connect( ClientSocket, (SOCKADDR*) &ClientAddr,
		 sizeof(ClientAddr) ) != SOCKET_ERROR)
	setsockopt( ClientSocket, IPPROTO_TCP, TCP_NODELAY,
		 (char*)&t, sizeof(t) );
	send( ClientSocket, "Hello", sizeof("Hello"), 0 );

"Lesley Anne" <mspfila-ng@yahoo.com> wrote in message
news:452d5df9@newsgroups.borland.com...

> I would assume that with a TTcpClient the equivalent
> would probably be TcpClient1->Handle

That is correct.


Gambit

Bob Gonder wrote:
>
> I think, if you followed Lesley's code, it would be wrong.
> I think you need to Open() first, so you have a valid socket
> to set the option on.

You're right.  The code I had we had originally copied from some message 
here, and used as-is, thinking it worked, but I wasn't checking the actual 
return value.  My boss and I just did a test and we are getting back a -1 
return with an error of 10038 (WSAENOTSOCK).  It looks like I've got a few 
changes to make.

Well, at least it's an easy change.  The call to setsockopt() was set up 
correctly.  It was just in the wrong position.  It should be right after the 
call to Open() rather than right before it.  This way it works:


   BOOL enabled = TRUE;

   ClientSocket1->Open();
   setsockopt((SOCKET)ClientSocket1->Socket->SocketHandle, IPPROTO_TCP,
                     TCP_NODELAY, (char*)&enabled, sizeof(BOOL));