In languages like PHP, where the application must explicitly start to listen to the server and fail if it receives nothing in a certain timeout, using commands like "listen" can cause the connection to break unless listen produces something in the timeout interval.
To remedy this problem currently, clients need to send a continious ping command to keep the connection busy while they "listen". This however entails an unnecesary performance penalty, since the ping itself isn't really necessary - any data would do, as long as it is available within the timeout interval.
A more efficient solution would be to have a dedicated command that sends an empty !re reply at a certain specified interval OR if the listen command does that if an optional argument with an interval is specified (since the listen command is really where the problem is). Personally, I'd prefer the latter, but I'll be happy with the first too.
/ip/arp/listen .tag=arp =keep-alive-interval=2s
would return (after 4s, if nothing happens during that time):
or if something (in this case a deleted item) has happened within that time:
Joined: Tue Feb 14, 2006 9:46 am Posts: 5434
Location: Riga, Latvia
you have to change that in PHP as there are no such issues with sockets. That should be configurable in PHP settings as that deviates from experience on all languages i know of. Technically TCP connection should be opened and never closed unless one of the ends imposes some artificial timeout value. Take for example SSH client connections - stays opened for weeks.
also, if any other php setting fail you can send non-existing command to the router. It will kick the parser and reply that command does not exist. To be sure send md5 sum of some string as such command most probably will not be intreoduced into RouterOS
!trap =category=0 =message=no such command or directory (22083539850d5fc8428146d7f76a135d)
I'm aware of the stream_set_timeout() function, but that still terminates the connection if no data is received within the specific timeout. Sure, you can set the timeout to something long, but that's still a connection being terminated after that long time.
And during that receiving attempt, one can't send additional data until the receiving stops. To be more precise, one can't do anything, as the fread() function doesn't return until at least one packet is received (or there is something remaining in PHP's buffer). So sending non-existing commands isn't really possible.
I'll look into non blocking streams. Perhaps that will help. It will surely start to feel unnatural though.
Users browsing this forum: No registered users and 9 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum