PHP port contention problem?

Sathi

I have been trying to Google this for three days with no luck, here is my problem...

I am developing an application that does certain scripted functions for our helpdesk and networking groups and delivers the results via web interface. An example of some of the functionality is port status of a switch, router error tracking, performance monitoring, utilization...that kind of stuff. I'm using snmp to do pretty much everything and it works great and all is good except when 2 users try and do something invoking snmp calls at the exact same time. I did a line sniff to see what the deal was and this is what happens as an example:

User (A) requests port speed/duplex settings for a switch on the network, php starts sending out the snmpget calls needed...

User (😎 initiates a check for router errors a split second after User (A), while User (A)'s script is still doing its thing. The instant User(😎
does this User(A) stops making the needed snmp calls and just stops. They then need to close out of their web browser and log back in.

User (😎's request completes without a problem.

I am guessing this is caused by contention for the snmp port and php gets confused. What I don't get is I have some scripts that rely on telnet and they all go out on port 23 and can run at the same time with no problem, why not snmp? My google searches turned up AgentX and smux protocols, but I could not really tell if they are relevant to my problem. Am I trying to do something that snmp is not capable of?

The only idea I had for a work around for this is anytime PHP goes to do an snmp query it can check to see if port 161 is in use, and if it is sleep for a period of time and then try again. Does that sound like it would work? Any input would be greatly appreciated, thanks.

I am running the following configuration on windows 2003

Apache version 2.2.0
PHP version 5.1.2
MySQL version 5.0.18

etully

I suggest that you create a table in the database that will serve as a lock. When a request is made to perform an snmp action, you check the table to see if some other process is using SNMP right now. If not, then you update that table to indicate that this process is using snmp.

You could then unlock the database when the snmp action is done. The problem with this is that if the script crashes for some reason, then the table remains locked and will not become unlocked. So a better idea is for the lock to record a time stamp. If another process checks the table and sees the lock but the lock is greater than X seconds old (maybe 10 seconds? maybe 30?) Then the process assumes that the lock is old and outdated and resets the lock and proceeds with it's own snmp action. The drawback here is that if certain snmp processes take a long time, then other processes might try to run anyway causing a conflict.

Another completely different idea is to have a cron job that performs an snmp query once a minute and stores the results in a database. Then, any PHP processes that want an snmp update look to the datbase instead of performing an actual snmp query. This would guarantee that there's never more than one running and you could have 50 or even 500 php processes getting snmp data at the same time since they are reading a record from the datbase, not bothering the port. The drawback to this solution is that (A) the queries only happen once a minute and (😎 when php processes get the data, it's about 30 seconds old on average.

Sathi

Thank you for your suggestions. That was pretty much the conclusion I had come to myself and started to modify my code. But then I had an idea and ran this test:

What I tried doing is to see if another network application that uses SNMP would duplicate the same problem. To my surprise, it didn't. For example we have the Solar winds network management application running on the same machine as my web server. Solar Winds has a circuit utilization gauge that works by making SNMP calls to the router. I pretty much made an exact copy of this functionality, i.e. gathering utilization of the router by making SNMP calls to it. I was able to run both my utilization gauge and the solarwinds utilization gauge at the exact same time and both worked with no problem. So there goes my theory that it is a port contention problem. Maybe the problem is just with PHP itself? Maybe the solarwinds app tests the availability of the port before making a snmp call?

etully

I have had problems with PHP failing to close external processes. I think it has to do with using the exec() command. I find that I don't have the problem when I use popen() instead. That may or may not have been the issue for you - not sure. Using another app sounds like a good work around and you're lucky you had that option. If you didn't, throwing a flag or a lock is a good solution - but not when PHP leaves the process open indefinitely which can be a frustrating mess.

Sathi

Thank you again for your response. Unfortunately the other app doesn't do most of what we need so I need to solve this somehow. I am not using exec in this case, but I have run into that exact same problem. I was using exec() to call to ping.exe so I could ping our network through the web interface. Problem was if anyone interupted the script while it was running ping.exe became a hubng process which could only be killed by restarting apache. Luckily I found someone who wrote a ping socket for php so I was able to work it out without calling to the OS.