Possible problem with Internet event Client or Server?

[Ron]

Hmm,... strange. There is one place where I could imagine that the server drops an event. I've added a dialog box to that point. Could you check if that dialogbox actually pops up ?

http://www.girder.nl/temp/ieventc.zip

It will say something like "Dropped Event!!!"

-Ron

[Ron]

So of those 20% you DO get the connected event ? Right ? Check with the logger plugin, this is very crucial in finding the problem.

[Ron]

Okay replace the event server with this one

(removed)

Make sure that the version is : 1.1debug.

This one does not send all the status information, only the actuall eventstring. If something goes wrong this one will also popup the Dropped Event box.

Please try it.

[Ron]

ooops forgot an I

http://www.girder.nl/temp/ievents.zip

[Ron]

I think this is not related to the CPU usage bug. The old TCPIP server was generating the CPU load it self, now we have the problem of an external load that is getting in the way of Girder processing. We'll find the little bug though :-)

[Ron]

Please upgrade, and did you put this in the hardware directory ? This is a hardwareplugin.

[Ron]

Okay, those other things are fixable details. The most important part is that I know where the problem is,.. where I feared it would be. The input queue of Girder is currently based on the windows queue, but the semaphore locking locks it to a depth of 1,... that is enough if the computer is processings fast but when things get busy events are dropped.

Seems like I have to delve into writing my own event queue. I was planning on this for a next major release but it seems we need it pretty soon. I'll give it some real good thought this weekend and I hope to come up with a good implementation ( never made an event que and hints are welcome!)

[Ron]

I never found this bug. Can you describe how I can recreate it ?

[Ron]

I tested the client that I have here and it works fine. Maybe I fixed it already. Wait for the next release of Girder 3.2

[Mark F]

A thread safe FIFO isn't too hard to do. ;) I'll start a thread in the developer area so as to not pollute this thread.

[jediperry]

This sounds exactly the same as the problem I was having when dscalar was taking up all the cpu time on the recieving computer. Hope you solve it :)

[rickd]

Ok I have setup a command which requests data from my theta via the serial port plugin. This command is triggered by an internet client event coming from my machine upstairs.

request_status_theta

The client on the machine upstairs sends this to the HTPC which it receives and requests the data from the Theta. Then that receipt of data triggers an event (on serial data) which in turn send the data payload via the internet event client on the htpc which is received and parsed on the machine upstairs. ie both machines are clients and servers.

This works great 90% of the time. About 1 in 10 the machine downstairs does not receive the request_status_theta to kick this off.....it does see a connection but does not see the eventstring according to logger.

Note I am using your modified version of the client for puting a varaible into the payload.

Thanks Rick

[rickd]

No Ron did not give me dropped event it seems to happen about 20% of the time so very reproduceable.

I run XP on the upstairs machine sending the initial request and ME on the machine which is the server in the first instance for this request. No loss occurs in the return leg.

Thanks Rick

[rickd]

Yes Ron in logger the connection occurs and passes the eventstring fine and the serial port returns data and then the internet client on that server works perfect eveytime on the return leg.

on a failure the connection occurs ok but the event string is not passed and then there is a discconnect.

It seems to be more like 50% of the time now.

Rick

[rickd]

Ron that file is not there it says please see Ron file not found!!!

Rick

[rickd]

Ron this file is not recognised by girder it erros with software plugin not found I renamed it to ieventc.dll too?

I run XP and v3.12c do I need to upgrade first?

Rick

[rickd]

Ron it seems to be good now no more dropped events though I did get a couple of crashes when it was returning an event until I added a command action on a returned ievent. So what I mean is a client event sent without an action on receive seems to occassionally cause a crash.

Not missing any events now though.....

:)

[rickd]

there is still a small bug with the client.

When you put [event] in the payload feel and close girder and open it again it has the last bracket missing like so [event

so it has to be readded manually.

Rick

[rickd]

Great to see I'm pushing it to the limit :D

I have two good machines too....the one with the slink-e and girder upstairs is 1.4GHz thunderbird with 512MB, Geforce 3 Ti500 etc no slug

Current HTPC is an 850MHz duron, 256MB and Radeon. It was the one dropping the ip client events though the faster machine never dropped any ip events. The htpc does all the serial control too so it is receiving ip events and serail events constantly....this means I always know what state the gear is in and can act accordingly.

Rick

[rickd]

Ron any chance you can fix the small bug with the Internet Event payload cutting the bracket off after Girder is restarted.

Thanks Rick

[rickd]

I place a variable that pld1 equals like [event] for example not [pld1].

Remember this is server and client you sent thru for testing.

I am still using them. Perhaps it is the length of the variable in brackets

thanks rick