🚀 go-pugleaf

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