To Bruce. timestamps in incoming NetSimple packets?

[Simon Kemp]

Hi Bruce,

I'm working on a NetTalk-dependant application that is rather time-sensitive. Happens to use the FIX protocol to go about it's business (via NetTalk and the NetSimple class), placing orders on trading platforms ("buy x USD", "now's a good time to buy y CHF"). Very, very occasionally things go pear-shaped and our logging shows that unexpected seconds have past since we got a look (NetSimple.Process) at incoming packets from the platforms.

I'm not suggesting any problem with NetTalk, it smells like the relevant window "our side" is locking-up, not responding to events sent from NetTalk ("come get your packet") and we see it "late". But we are finding it difficult to diagnose what's happening during these very rare events. NetTalk's outputdebugstring logging isn't relevant here because we can't reproduce the problem, we need extra information to stuff into our disk logs on the machines that are running the application for real. That would help us zero-in, eliminate some suspicions, etc.

Short story is I'm wondering about two additions to your underlying "Packet" structure (the thing I look at in NetSimple.Process):-

#1. Haven't read too much about it, but think TCP can include an optional "sender timestamp". You can only know more about it than me, but if it's available then would it make sense to pass it "up" from NetTalk?

#2. Less vague, this is about inter-thread communication. In some way, maybe simple as today() and clock() tell the destination thread when NetTalk saw the thing (packet). Right now, it would be invaluable in trying to identify what's going on. We could stuff it in our disk log and see what it proves / disproves.

Not sure that's making a right lot of sense but I tried 

Thanks,
Simon
   

[Bruce]

Hi Simon,

>> it smells like the relevant window "our side" is locking-up, not responding to events sent from NetTalk ("come get your packet") and we see it "late"

This is often a sign that this window is calling some other procedure with a window at some point. For example MESSAGE or SendEmail or something like that. Because of the way events work, if you do open another window, then the notification events go there instead of to you.

Are you acting as a simpleClient or a SimpleServer? There are ways of "checking if anything is waiting" in either case (ie simulating a notification event) if you are in this sort of position.

>> #2. Less vague, this is about inter-thread communication. In some way, maybe simple as today() and clock() tell the destination thread when NetTalk saw the thing (packet). Right now, it would be invaluable in trying to identify what's going on. We could stuff it in our disk log and see what it proves / disproves.

This is a good idea, but would require a change to the DLL and class to add things to the packet structure. Ideally I'd prefer to do that leter in the year with NetTalk 9 - as much as possible I avoid changing the interface between the DLL and the class "during" a released version. That said, it's not impossible to tweak and obviously is fairly easy code, so yes that would at least identify "old" packets in the queue.

cheers
Bruce

[Simon Kemp]

Thanks Bruce,

SimpleClient and definitely not opening any windows.

There happen to be two NetSimple classes working on the same window but know that's not a challenge for NetTalk and 99.99% percent of the time everything works perfectly.

We've got the usual problem that we can't reproduce the issue or think why it would happen.

While I've got your attention. In real life, is it ever the case that packets can be severely delayed, arriving in NetTalk (say) 10 seconds after they appear to have been sent? The FIX protocol includes a SendingTime that tells us the other side have done their job and sent stuff winging our way...

Simon
 

[Simon Kemp]

Me again. Bruce, you said:-

> There are ways of "checking if anything is waiting" in either case (ie simulating a notification event) if you are in this sort of position.

Could anyone expand on that (simpleclient). Seems to raise the possibility of running without a window and accept loop, which might be ideal for this...

Thanks
 

[Bruce]

Hi Simon,

>> Seems to raise the possibility of running without a window and accept loop, which might be ideal for this...

no, that's absolutely not the case. The comms is asynchronous so it definitely needs a window and an Accept loop.

>> While I've got your attention. In real life, is it ever the case that packets can be severely delayed, arriving in NetTalk (say) 10 seconds after they appear to have been sent?

there are a few factors that affect the "speed" from one program, on one machine to another program on a different machine. In concept the packets travel through 7 layers on each side, from the app itself through various OS layers then through the wire, via all the routers and so on.

So yes, it is certainly possible for packets to be delayed - especially if the bandwidth and either end is congested. I would say it's "rare" but of course it's also not uncommon (look at how long even simple web sites takes sometimes.)

Certainly TCP/IP is not a "guaranteed delivery time" protocol - so you can't just rely on the packet going through at some pre-determined speed.

That said I don't think this is the cause of your problem.

>> The FIX protocol includes a SendingTime that tells us the other side have done their job and sent stuff winging our way...

I'm not sure what the FIX protocol is, or what that means in the long run...(If the sender wanted to send you the time, it would be handy if they simply added that to the packet, or the header.)

>> Could anyone expand on that (simpleclient).

Calling the .Process method will cause it to look in the DLL for waiting packets (and of course most likely gracefully do nothing.) You might trigger this .Process from a timer (although in your case that might not be the optimal way) or you might have some other event (like completing a message) that triggers the next one.

Presumably, since this is NetSimple you are managing the case where the incoming message is split across 2 incoming packets?

cheers
Bruce

[Simon Kemp]

Thanks Bruce,

That all makes sense.

> Presumably, since this is NetSimple you are managing the case where the incoming message is split across 2 incoming packets?
 
Yes, that wasn't the problem. Turned out to be some errant code crippling the thread and stalling the receipt of packets from NetTalk.

Simon