Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - routinet

Pages: [1]
1
0x1337c0de / Re: PHP problems on verification of server offline/online
« on: December 22, 2010, 03:10:35 AM »
You're right.  Brain fart on my part; sorry for the noise.

Good to know I was not just missing something smack in front of my face.  As I said, I don't deal with sockets much, so I'm not intimately familiar with their behavior.  That saves me the trouble of rewriting my rewrite.  :P 

A guess: If the orignal page is being hosted on the same system as the Q2 servers being pinged, perhaps the OS kernel is helping to shortcut the delay by providing an 'unreachable' response, resulting in an immediate EOF on the fread().

A good guess, and one I should have caught on to seeing as how the socket target is the same domain as the response.  (there's that "smack in front of my face" thing again...) 

 :rockon: :afro:

2
0x1337c0de / Re: PHP problems on verification of server offline/online
« on: December 21, 2010, 11:52:37 PM »
I rarely work with sockets, so I appreciate you entertaining my ignorance...

However, it should be noted that the refactored code will be significantly slower than the original to obtain all its results.

The original sent out all the UDP requests in parallel, and thus only had to wait for the results as long as the single slowest reply took to arrive.

Can you provide benchmarks for that assertion?  I understand fread()/fwrite() are supposed to function asynchronously, but those calls are mixed with necessarily synchronous code in both samples.  In the original code, all of the sockets would be opened asynchronously, but the writing to/reading from would happen in order of appearance, yes?  e.g., the second write does not begin until after the first response has been received.

In my tests, both ran with roughly equivalent times.  My tests only added stream_set_timeout() after fsockopen(), for my own sanity, setting the timeout to 1 second.  Which brings up a curiosity:

About the servers that do not return the ping...how does the original code bypass the default timeout of 60 seconds?  The actual page loads quickly, so either all servers are returning *something*, or the timeout is being set somewhere other than the sample provided...?  All of the offline servers triggered the timeout when I ran the code.

Pages: [1]