🚀 go-pugleaf

"Martin" <dev@no.comppromed.spam.com> wrote in message
news:44281b29$1@newsgroups.borland.com...

> The connection that gives me the problem is one that has periods
> where nothing is sent/receive for more than 20 minutes.

Sockets themselves do not have any problems with idle periods.  They don't
care at all whether data is being transmitted frequently or not.  So any
problems you are having are likely caused by problems in your own code that
is managing the sockets.

> The socket is still connected (no disconnect events or errors), but
> later on we find that the other side tried to send something that wasn't
> received by our app.

What does your actual code look like?  Since you are using non-blocking
sockets, my first guess would be that you are not completely clearing the
socket's inbound buffer when data arrives, thus the socket eventually begins
losing notifications when new data arrives.  When data arrives, you have to
read ALL of it at that moment, into your own buffer.  You should not leave
data unread in the socket in between events.


Gambit

Remy Lebeau (TeamB) wrote:
> "Martin" <dev@no.comppromed.spam.com> wrote in message
> news:44281b29$1@newsgroups.borland.com...
> 
> 
>>The connection that gives me the problem is one that has periods
>>where nothing is sent/receive for more than 20 minutes.
> 
> 
> Sockets themselves do not have any problems with idle periods.  They don't
> care at all whether data is being transmitted frequently or not.  So any
> problems you are having are likely caused by problems in your own code that
> is managing the sockets.
> 
> 
>>The socket is still connected (no disconnect events or errors), but
>>later on we find that the other side tried to send something that wasn't
>>received by our app.
> 
> 
> What does your actual code look like?  Since you are using non-blocking
> sockets, my first guess would be that you are not completely clearing the
> socket's inbound buffer when data arrives, thus the socket eventually begins
> losing notifications when new data arrives.  When data arrives, you have to
> read ALL of it at that moment, into your own buffer.  You should not leave
> data unread in the socket in between events.
> 
> 
> Gambit
> 
> 

I don't think I'm leaving anything in the input 
buffer. Here's the OnRead event:
void __fastcall socketClass::onRead( TObject 
*Sender, TCustomWinSocket *Socket)
     {
     char buf[ 4096];

     for (;;)
         {
         int numBytes = Socket->ReceiveBuf( buf, 
sizeof( buf));
         if (numBytes <= 0)
             break;

         if (cfg.comDiag > 1)
             audit( HERE, "%s %s:onRead - Recving 
%d bytes\n",
                 currentTime(), this->sktId, 
numBytes);

         this->inBuf->writeData( buf, numBytes);
         }
     } /* socketClass::onRead() */



inBuf is a ring buffer class that we wrote years 
ago. It stores the data until the app has a chance 
to get around to it (within 0.5 sec.).  It's 
possible that the ring buffer is messing with me 
but it's been in use longer than the underlying 
socket stuff. I'm double checking tonight to see 
if we're getting the audit info from the read 
event. Unfortunately, this problem only happens 
overnight.

Marty

"Martin" <dev@no.comppromed.spam.com> wrote in message
news:44285053$1@newsgroups.borland.com...

> I don't think I'm leaving anything in the input
> buffer. Here's the OnRead event:

You should be calling ReceiveLength() before calling ReceiveBuf()

    void __fastcall socketClass::onRead(TObject *Sender, TCustomWinSocket
*Socket)
    {
        char buf[ 4096];
        int numBytes;

        do
        {
            numBytes = Socket->ReceiveLength();
            if( numBytes > 0 )
                numBytes = Socket->ReceiveBuf(buf, min(sizeof(buf),
numBytes));

            if( numBytes < 1 )
                break;

            if( cfg.comDiag > 1 )
                audit( HERE, "%s %s:onRead - Recving %d bytes\n",
currentTime(), this->sktId,  numBytes);

            inBuf->writeData(buf, numBytes);
        }
        while( true );
    }

> inBuf is a ring buffer class that we wrote years ago. It stores the
> data until the app has a chance to get around to it (within 0.5 sec.).
> It's possible that the ring buffer is messing with me but it's been in
> use longer than the underlying socket stuff.

Are you sure that you are not filling the buffer beyond its capacity,
overriding the surrounding memory?

Did you verify that the sending application is actually sending its data
without errors?

Also, non-blocking sockets rely on the message queue, so are you blocking
the queue at any time from processing new messages?

Are there are firewalls or routers in between your application and the
sending application, which might be blocking the data?


Gambit

Remy Lebeau (TeamB) wrote:
> "Martin" <dev@no.comppromed.spam.com> wrote in message
> news:44285053$1@newsgroups.borland.com...
> 
> 
>>I don't think I'm leaving anything in the input
>>buffer. Here's the OnRead event:
> 
> 
> You should be calling ReceiveLength() before calling ReceiveBuf()

Why? I can see that it would limit the amount of 
data read to the current incoming amount, but the 
underlying socket in windows should take care of 
any buffering stuff and the message queues.

> Are you sure that you are not filling the buffer beyond its capacity,
> overriding the surrounding memory?

No, it's not overwriting the surrounding memory. 
And the buffer is much bigger than the incoming 
packets.

> Did you verify that the sending application is actually sending its data
> without errors?

Yes. During the timeframe where it's not working, 
they're sending and resending, but no response 
from us.

> Also, non-blocking sockets rely on the message queue, so are you blocking
> the queue at any time from processing new messages?

No. The other sockets still work during this time. 
As does the rest of the application.

> Are there are firewalls or routers in between your application and the
> sending application, which might be blocking the data?

No. Both apps are on a LAN (same subnet), and I 
don't see how a "reboot" would clear a block from 
any router they may have. There is not a firewall 
running on our side.

When it happened last night, I did not get any of 
the auditing statements from the read event. So 
either no events happened or the underlying recv() 
calls always returned 0.

Marty

"Martin" <dev@no.comppromed.spam.com> wrote in message
news:44298fd1$1@newsgroups.borland.com...

> No, it's not overwriting the surrounding memory. And the buffer is
> much bigger than the incoming packets.

That does not mean that the buffer is not filling up, if the application is
not removing data from the buffer faster than it arrives.

> During the timeframe where it's not working, they're sending and
> resending, but no response from us.

How are you verifying that, though?  Did you try using a packet sniffer to
make sure that data is actually reaching your machine?

> When it happened last night, I did not get any of
> the auditing statements from the read event. So
> either no events happened or the underlying recv()
> calls always returned 0.

recv() returns 0 when the socket has been disconnected by the other party.
If there is no data available but the connection is still active, then
recv() will return SOCKET_ERROR and WSAGetLastError() returns
WSAEWOULDBLOCK.

You should be using ReceiveLength() before ReceiveBuf() to make sure that
there is any data available for reading before you attempt to actually read
it.


Gambit