LNET CanSend is not always triggerd

[MaartenJB]

Hi,

I've got a simple lnet client server, the client sends data to the server, but once out of about 10 times the "CanSend" is not being triggered on the client side. When I do a manual trigger like this: "TcpClientCanSend( TcpClient.Iterator )" the sending continues successfully.

I've attached the source of a very basic application that shows the problem. It automatically connects and disconnects and detects if a CanSend has been fired or not. Sometimes it fails right away, sometimes it takes a while. When it fails there is a button "Force CanSend" and when pressed it continues.

I've also attached two pictures, one of how it should look and one where the CanSend is not fired.

debug-tcp-client-server.zip

Best regards,

Maarten

[almindor]

Hey, thanks for reporting. I'm a bit busy right now but will try to take a look soon.

One thing that comes to mind right off the bat is that CanSend is only fired if you got a state where you COULDN'T send before. In other words you'd need to fill the send buffer of the OS fully before a new CanSend will be fired. It is triggered opposed to recevies so the state you're in by default is "I can send".

Is it possible you didn't loop sends until you got a 0 back?

[MaartenJB]

Hi Almindor,

Thanks for your fast reply. Well actually I'm not even sending data in this example, just connect and disconnect.

I have this code in "TcpClientReceive(aSocket: TLSocket)":

while (aSocket.GetMessage(s) > 0) do MyDebug('Data: ' + s, ttTcpClient);

GetMessage always returns "0", because I'm not sending any data yet.

[almindor]

That's not how this is supposed to be used.

You're supposed to register OnReceive and OnCanSend (and OnError) handlers on both sides of the connection (if both use lNet). That way you know when something comes in because you get OnReceive, and you know when your sending channel opens up again if it got filled because you get OnCanSend.

OnCanSend is edge-triggered which means it only fires when the status changes from "cannot send" to "can send again".

You're not supposed to use loops or waits with lNet. The CallAction call takes care of the main loop, either directly in the "console" version of lNet when you call it in your main loop, or indirectly with "visual" lNet when it's hooked up to the application's main event loop.

[MaartenJB]

So after a connect it is normal for OnCanSend to not always be triggered?

Did you have a chance to look at my source code? because I think I have done what you said above, and registered all event handlers for both the client and the server side. Maybe I must change the while loop to an if statement, but it never runs more than once, and the MyDebug doesn't run at all in the TcpClientReceive Handler, so I have no delays in my code.

[MaartenJB]

Hi Ales,

Did you have a chance to look at my code?

Best regards,

Maarten

[almindor]

Sorry I've been crazy busy since we moved recently. I'll try and check your code out but in the meantime here's the logic:

I'm assuming all event handlers are registered.

1. CallAction must be called continuously in a loop. If you're using the "visual" components this is taken care for you, otherwise you have to do this yourself.
2. OnCanSend will NOT be triggered under normal circumstances, not even once!
3. OnCanSend will ONLY be triggered if you kept sending and filled the OS buffer. Once that happens your send will return a EAGAIN error and you need to wait for OnCanSend

So for a typical scenario when you're just sending a small chunk or only send occasionally you call connect (or listen), wait for OnConnected or OnAccepted and then you proceed to send as you need.