server programming

markbsure

hey

we're writing some server side code in an AMX module, to allow a Pr0nt0 touch panel to communicate via IP and basically emulate an AMX touch panel.

it's working really well, and the speed/responsiveness is pretty amazing - it seems to control our satellite boxes (pronto - (ip) - amx - (ir) - sat box) faster and more exactly than the sat box's original IR handset!!

we have found one bug... and this is that the Pr0nt0 doesn't always seem to catch the AMX closing the server (in the case of an AMX reboot for example) and therefore doesn't close it's socket.... we believe this to be a fault in the Pr0nt0 side of the communications but i'd like to check i'm programming the AMX server side correctly......

I run "IP_SERVER_OPEN" once in "DEFINE_START" within the module. Should I have to worry about the server closing at any time other that when the AMX processor loses its power?

How do I monitor whether the server is open or closed? If i monitor the ONLINE and OFFLINE events of the IP DPS i'm opening the server on, these events only seem to be triggered when a client connects to the server... is this correct?

Is it possible to run multiple instances of my module, using different ports for each one? Is there any problem with running multiple servers on an AMX processor?

thanks

bcirrisi

Mark,

Sounds like you are really close. Here's one approach (I have a couple)...

1. Create a persistent variable that tracks if the device is on-line or not based on the ONLINE and OFFLINE events.

2. Check the value of the on-line tracking variable during Startup. If the variable says it online, issue a IP_SERVER_CLOSE. This has worked in the past, even though you get a couple of errors in Telnet.

3. You can and probably should open multiple Server Ports, just make sure that they are consecutive. It would look something like this.

nServerSocket_x1 = IP_SERVER_OPEN (21, 1024, 1)
nServerSocket_x2 = IP_SERVER_OPEN (22, 1024, 1)
nServerSocket_x3 = IP_SERVER_OPEN (23, 1024, 1)
nServerSocket_x4 = IP_SERVER_OPEN (24, 1024, 1)
nServerSocket_x5 = IP_SERVER_OPEN (25, 1024, 1)

Every time something connects to that port (1024) it will go to the next available socket (local ports 21-25). This is also a good technique if you plan on connecting more then one device.

4. And you should worry about the server closing besides when the NI reboots. To safeguard this re-issue the IP_SERVER_OPEN on the OFFLINE event for that IP_SERVER_OPEN instance.

Cool?

jweather

Depends on what the problem is. If the problem only shows up when the AMX processor reboots, it's probably the Pronto side getting "stuck" with an open connection and not trying to reconnect. Nothing you do on the AMX side will change this. If you have control over the Pronto side, have it send a "ping" or "noop" command every few seconds. That may cause it to realize the connection has been dropped sooner than it would notice otherwise. Even if you can't do that, though, it should be noticing and reconnecting as soon as you try to send a command. What's happening on the AMX side when it gets "stuck" like that?

I don't know of anything that would close an open server, short of a reboot. The OFFLINE event indicates that a client has disconnected.

markbsure

Thanks for your pointers guys.

Just to confirm what i've found, after much testing and playing around, it seems that:

the online event of the server DPS is triggered only when a client connects.
the offline event of the server DPS is triggered when a client disconnects, and occasionally this will cause the server to close its socket.

(telnet to processor and send "ip status" to see the status of all IP comms whilst devices connect and disconnect)

I now track whether the client is connected using the online and offline events of the server DPS, and always close the server, then re-open it when i receive an offline event.

The only way to track whether the server has opened successfully seems to be on the result of the command, IP_SERVER_OPEN (0 = operation was successful, other values = various errors... see the help file).