🚀 go-pugleaf

Hi Remy,

Thanks for you response...

I am confused on exactly how to implement the call to setsockopt.  My
implementation uses Borland's TClientSocket. Adding the the setsockopt to my
routine looks like this...

void __fastcall TCBConfirm::StartButtonClick(TObject *Sender)
   {
   bool RetVal = true;
   bool bOptVal = true;
   int bOptLen = sizeof(bool);

   if (setsockopt(MainForm->DigiLANClientSocket->Socket,
IPPROTO_TCP,TCP_NODELAY,(char*)&bOptVal,bOptLen) != SOCKET_ERROR)
      RetVal = false;

   if (RetVal)
      ShowMessage("Option Set!!");


   StartButton->Enabled = false;
   DCDialForm->ConfirmCBLogOff();
   MainForm->DigiLANClientSocket->Active = false;
   MainForm->Client = false;
   MainForm->DigiLANServerSocket->Active = true;
    }


The compiler complains about
[C++ Error] CallBackConfirm.cpp(28): E2034 Cannot convert 'TClientWinSocket
* const' to 'unsigned int'
[C++ Error] CallBackConfirm.cpp(28): E2342 Type mismatch in parameter 's'
(wanted 'unsigned int', got 'TClientWinSocket *')

It would appear that I need to specify the(socket)
"MainForm->DigiLANClientSocket->Socket"  in another manner, but I am
uncertain exactly how to specify it.

Thanks for your response...

Joe





"Remy Lebeau (TeamB)" <gambit47.no.spam@no.spam.yahoo.com> wrote in message
news:40ef26e6$1@newsgroups.borland.com...
>
> "Joe St. Onge" <jstonge@nel-techlabs.com> wrote in message
> news:40eee74d$1@newsgroups.borland.com...
>
> > Anyone know how to change the BB TServe Socket operation
> > to force it to transmit smaller packets instead of the 1K???
>
> Try disabling the Nagle algorithm so that data is send immediately instead
> of being buffered.  Use the Win32 API setsockopt() function directly,
> specifying the TCP_NODELAY operation:
>
>     level = IPPROTO_TCP
>     value: TCP_NODELAY
>     type: BOOL
>     meaning: Disables the Nagle algorithm for send coalescing.
>
>     The TCP_NODELAY option is specific to TCP/IP service providers.
Enabling
> the TCP_NODELAY option disables the TCP Nagle Algorithm (and vice versa).
> The Nagle algorithm (described in RFC 896) is very effective in reducing
the
> number of small packets sent by a host by essentially buffering send data
if
> there is unacknowledged data already "in flight" or until a full-size
packet
> can be sent. It is highly recommended that TCP/IP service providers enable
> the Nagle Algorithm by default, and for the vast majority of application
> protocols the Nagle Algorithm can deliver significant performance
> enhancements. However, for some applications this algorithm can impede
> performance, and TCP_NODELAY can be used to turn it off. These are
> applications where many small messages are sent, which need to be received
> by the peer with the time delays between the messages maintained.
> Application writers should not set TCP_NODELAY unless the impact of doing
so
> is well-understood and desired, since setting TCP_NODELAY can have a
> significant negative impact of network and application performance.
>
>
> Gambit
>
>