Ping+Port Routine?

Hi! I'm trying to write a small application for an online gaming site
(flight sims), where people can add their local server to a list.

Basically, I just need to be able to loop/ping each respective server
- via a specific port (2934 or 2935) to see whether the server is
still "live", so the hosters don't have to manually update their
status on the site.

Everything I've seen seems overly complex. Efforts so far have
returned info via a traditional PING, but I can't seem to find an easy
way of getting the required *port* info. The script would have to run
from a regular hosted site, so I wouldn't have much access to the
server's "innards".

Any ideas?

TIA - Adam.

Adam wrote:[color=blue]
> Hi! I'm trying to write a small application for an online gaming site
> (flight sims), where people can add their local server to a list.
>
> Basically, I just need to be able to loop/ping each respective server
> - via a specific port (2934 or 2935) to see whether the server is
> still "live", so the hosters don't have to manually update their
> status on the site.
>
> Everything I've seen seems overly complex. Efforts so far have
> returned info via a traditional PING, but I can't seem to find an easy
> way of getting the required *port* info. The script would have to run
> from a regular hosted site, so I wouldn't have much access to the
> server's "innards".
>
> Any ideas?
>
> TIA - Adam.[/color]

Ping uses an internally defined port for responses - not just any port.
You can't ping a specific port - it wouldn't know how to respond.

Probably the easiest way would be to use fsockopen to open a socket to
the appropriate system/port.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Wed, 21 Sep 2005 07:05:41 -0500, Jerry Stuckle wrote:
[color=blue]
>Adam wrote:[color=green]
>> Hi! I'm trying to write a small application for an online gaming site
>> (flight sims), where people can add their local server to a list.
>>
>> Basically, I just need to be able to loop/ping each respective server
>> - via a specific port (2934 or 2935) to see whether the server is
>> still "live", so the hosters don't have to manually update their
>> status on the site.
>>
>> Everything I've seen seems overly complex. Efforts so far have
>> returned info via a traditional PING, but I can't seem to find an easy
>> way of getting the required *port* info. The script would have to run
>> from a regular hosted site, so I wouldn't have much access to the
>> server's "innards".
>>
>> Any ideas?
>>
>> TIA - Adam.[/color]
>
>Ping uses an internally defined port for responses - not just any port.
> You can't ping a specific port - it wouldn't know how to respond.
>
>Probably the easiest way would be to use fsockopen to open a socket to
>the appropriate system/port.[/color]

Thanks for that. I've managed to send an initial "handshake" packet
out to the game server using:

$handle = fsockopen("udp://$host", $port, $errno, $errstr, $timeout);

It triggers the game server to respond with a 67 byte long reply
(which I can see using a packet sniffer). So far so good.

However ... try as I might, I just can't read this data. I've tried
all sorts of combinations of "fread", "unpack" etc. eg:

$contents = fread($handle, 67);

The above seems to return nothing. How do I go about reading this
packet of data? Is the PHP code executing before the packet has had a
chance to arrive?

Thanks,

Adam.

Adam wrote:[color=blue]
> On Wed, 21 Sep 2005 07:05:41 -0500, Jerry Stuckle wrote:
>
>
>
> Thanks for that. I've managed to send an initial "handshake" packet
> out to the game server using:
>
> $handle = fsockopen("udp://$host", $port, $errno, $errstr, $timeout);
>
> It triggers the game server to respond with a 67 byte long reply
> (which I can see using a packet sniffer). So far so good.
>
> However ... try as I might, I just can't read this data. I've tried
> all sorts of combinations of "fread", "unpack" etc. eg:
>
> $contents = fread($handle, 67);
>
> The above seems to return nothing. How do I go about reading this
> packet of data? Is the PHP code executing before the packet has had a
> chance to arrive?
>
> Thanks,
>
> Adam.[/color]

From the PHP manual:

Warning:
UDP sockets will sometimes appear to have opened without an error, even
if the remote host is unreachable. The error will only become apparent
when you read or write data to/from the socket. The reason for this is
because UDP is a "connectionless" protocol, which means that the
operating system does not try to establish a link for the socket until
it actually needs to send or receive data.

So - just because you get a handle back doesn't mean you've successfully
opened the socket. You may not actually be opening it. You many need
to use a packet sniffer to see what's actually going across your link.

Otherwise, if just opening the socket gets you the response, I would
expect you to get the response. Are you sure you don't need to send
something first, i.e. a newline char?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Thu, 22 Sep 2005 11:23:15 -0500, Jerry Stuckle wrote:
[color=blue]
>Adam wrote:[color=green]
>> On Wed, 21 Sep 2005 07:05:41 -0500, Jerry Stuckle wrote:
>>
>> Thanks for that. I've managed to send an initial "handshake" packet
>> out to the game server using:
>>
>> $handle = fsockopen("udp://$host", $port, $errno, $errstr, $timeout);
>>
>> It triggers the game server to respond with a 67 byte long reply
>> (which I can see using a packet sniffer). So far so good.
>>
>> However ... try as I might, I just can't read this data. I've tried
>> all sorts of combinations of "fread", "unpack" etc. eg:
>>
>> $contents = fread($handle, 67);
>>
>> The above seems to return nothing. How do I go about reading this
>> packet of data? Is the PHP code executing before the packet has had a
>> chance to arrive?
>>
>> Thanks,
>>
>> Adam.[/color]
>
> From the PHP manual:
>
>Warning:
>UDP sockets will sometimes appear to have opened without an error, even
>if the remote host is unreachable. The error will only become apparent
>when you read or write data to/from the socket. The reason for this is
>because UDP is a "connectionless" protocol, which means that the
>operating system does not try to establish a link for the socket until
>it actually needs to send or receive data.
>
>So - just because you get a handle back doesn't mean you've successfully
>opened the socket. You may not actually be opening it. You many need
>to use a packet sniffer to see what's actually going across your link.
>
>Otherwise, if just opening the socket gets you the response, I would
>expect you to get the response. Are you sure you don't need to send
>something first, i.e. a newline char?[/color]

Jerry - thanks for persevering with me on this one <g>. Yep - I'd read
that warning in the manual.

There's no problem with *writing* to the [opened] socket. Using a
packet sniffer, I can see the data go out and - what's more - I can
see a response packet appear on the client. This is what's happening:

1) Open socket (in client).
2) Write to socket (gets sent successfully to game server).
3) Client gets response back from server (socket still open).
4) Futile attempts to read the 67 bytes long incoming packet (!!).
5) Close socket (in client).

For step 4, I've tried fread, fgets .. all sorts - but it occurs to me
that this may be a PHP/OS related thing, as I've seen (in my Googling)
reference to a *read* socket bug in PHP in earlier builds for Win32.

Are you suggesting I send something [again] before steps 3,4? Is it a
*timing* problem? Either the PHP script isn't waiting long enough for
the incoming packet or the packet has beenand gone before the script
has had a chance to read it?

All examples I've tried using (eg. HTTP/port 80) seem to work fine - a
request gets sent and the response is processed properly and
displayed.

My setup is Apache/2.0.52 (Win32) PHP/4.3.9. I'll try running the
client script from a Linux machine.

Adam.

Adam wrote:[color=blue]
> On Thu, 22 Sep 2005 11:23:15 -0500, Jerry Stuckle wrote:
>
>
>
> Jerry - thanks for persevering with me on this one <g>. Yep - I'd read
> that warning in the manual.
>
> There's no problem with *writing* to the [opened] socket. Using a
> packet sniffer, I can see the data go out and - what's more - I can
> see a response packet appear on the client. This is what's happening:
>
> 1) Open socket (in client).
> 2) Write to socket (gets sent successfully to game server).
> 3) Client gets response back from server (socket still open).
> 4) Futile attempts to read the 67 bytes long incoming packet (!!).
> 5) Close socket (in client).
>
> For step 4, I've tried fread, fgets .. all sorts - but it occurs to me
> that this may be a PHP/OS related thing, as I've seen (in my Googling)
> reference to a *read* socket bug in PHP in earlier builds for Win32.
>
> Are you suggesting I send something [again] before steps 3,4? Is it a
> *timing* problem? Either the PHP script isn't waiting long enough for
> the incoming packet or the packet has beenand gone before the script
> has had a chance to read it?
>
> All examples I've tried using (eg. HTTP/port 80) seem to work fine - a
> request gets sent and the response is processed properly and
> displayed.
>
> My setup is Apache/2.0.52 (Win32) PHP/4.3.9. I'll try running the
> client script from a Linux machine.
>
> Adam.[/color]

Hi, Adam,

OK, I didn't realize you were sending to the remote machine first. OK,
so we know the socket itself is open, you can write to it, and you get a
response back.

Next thing - fread stops as soon as a packet is available. This may or
may not be the entire message. An extreme example - say the remote
system is sending you 100K worth of data. This won't all come in one
packet - you probably will have at least dozens of them. fread() will
read one packet, and you'll have to keep to keep receiving until you get
all the data, and assemble the packets.

How does this apply in your case? Well, is it possible you're getting a
short (or empty) packet before the data? It's perfectly legal for the
remote to do so. If so, you'll have to loop on your fread() call until
you get all 67 bytes of data.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Fri, 23 Sep 2005 10:07:59 -0500, Jerry Stuckle wrote:
[color=blue]
>Adam wrote:[color=green]
>> On Thu, 22 Sep 2005 11:23:15 -0500, Jerry Stuckle wrote:
>>
>>
>>
>> Jerry - thanks for persevering with me on this one <g>. Yep - I'd read
>> that warning in the manual.
>>
>> There's no problem with *writing* to the [opened] socket. Using a
>> packet sniffer, I can see the data go out and - what's more - I can
>> see a response packet appear on the client. This is what's happening:
>>
>> 1) Open socket (in client).
>> 2) Write to socket (gets sent successfully to game server).
>> 3) Client gets response back from server (socket still open).
>> 4) Futile attempts to read the 67 bytes long incoming packet (!!).
>> 5) Close socket (in client).
>>
>> For step 4, I've tried fread, fgets .. all sorts - but it occurs to me
>> that this may be a PHP/OS related thing, as I've seen (in my Googling)
>> reference to a *read* socket bug in PHP in earlier builds for Win32.
>>
>> Are you suggesting I send something [again] before steps 3,4? Is it a
>> *timing* problem? Either the PHP script isn't waiting long enough for
>> the incoming packet or the packet has beenand gone before the script
>> has had a chance to read it?
>>
>> All examples I've tried using (eg. HTTP/port 80) seem to work fine - a
>> request gets sent and the response is processed properly and
>> displayed.
>>
>> My setup is Apache/2.0.52 (Win32) PHP/4.3.9. I'll try running the
>> client script from a Linux machine.
>>
>> Adam.[/color]
>
>Hi, Adam,
>
>OK, I didn't realize you were sending to the remote machine first. OK,
>so we know the socket itself is open, you can write to it, and you get a
>response back.
>
>Next thing - fread stops as soon as a packet is available. This may or
>may not be the entire message. An extreme example - say the remote
>system is sending you 100K worth of data. This won't all come in one
>packet - you probably will have at least dozens of them. fread() will
>read one packet, and you'll have to keep to keep receiving until you get
>all the data, and assemble the packets.
>
>How does this apply in your case? Well, is it possible you're getting a
>short (or empty) packet before the data? It's perfectly legal for the
>remote to do so. If so, you'll have to loop on your fread() call until
>you get all 67 bytes of data.[/color]

Well ... the story continues <ggg>. Basically though, it appears that
whichever way I try to read the data, it hangs. This is using fread,
fgets, socket reads ... you name it. The *impression* I get is that
the packet has already been and gone - and all attempts to read the
socket fail - because the [remote] server is no longer sending.

I know (via the portsniffer) that the incoming packet is less than 100
bytes long. It's not a file (I don't think) so it won't have an eof
marker.

I've just installed PHP5 with socket support on a Linux machine to see
whether any of the socket_* commands or new PHP5 functions will work.

Watch this space <g> ...

Adam.

Still no luck :-((

I have Ethereal running on both client and server. Both versions
confirm that:

1) A request goes out to the server on port 2934. This is around 70
bytes: A header plus around 30 bytes of data.
2) The server responds with a welcome of around 120 bytes.
3) This packet duly arrives at the client.

OK - now to the code. I've tried every combination of socket connect &
write, streams .. you name it ...but here are my two main variations:

// Set up the connection ===================
$remote_host = 'udp://192.168.1.126';
$remote_port = 2934;
$timeout = 1;

// This is the outgoing msg (in hex) ==========
$hello =
"\x20\x00\x09\x42\x46\x4f\x31\x00\x00\x00\x00\x01\ x83\x05\x07\x0d\x12";

// This part embeds the client's IP address (in hex, backwards!)
// This is what the connecting flight sim appears to send
$hello .="\x03\x01\xa8\xc0";

// The rest of the data packet:- (sim version etc).
$hello .= "\x03\x84\x0f\x87\x12\x02\x00\x00";

// The returned data (I should be so lucky!) =====
$ret = '';

// Open the socket ================
$socket = fsockopen($remote_host, $remote_port, $errno, $errstr,
$timeout);
if (!$socket) {
echo "Connection Failed - Please check manually."; }
else {
// Send the packet ===
fputs($socket, "$hello");
// fputs($socket, "$hello\r\n"); // Try with a return? ===

echo "Sent to $remote_host:$remote_port ";

// So far so good ... the packet gets received
// by the server (confirmed by sniffer) ...
// and a reply gets sent to the client IP+port ..

//... BUT ... neither of these appear to work =======
//$ret = fgets($socket, 64);
$ret = fread($socket, 2048);
// Tried all sorts values from 1 to 2048 =====

echo "[" . $ret . "]";
fclose($socket);
};
echo "<hr>Closed";

That's it! H-E-L-P !!! I wonder whether you/anyonecan shed any light
on this!

Adam.

Adam wrote:[color=blue]
> Still no luck :-((
>
> I have Ethereal running on both client and server. Both versions
> confirm that:
>
> 1) A request goes out to the server on port 2934. This is around 70
> bytes: A header plus around 30 bytes of data.
> 2) The server responds with a welcome of around 120 bytes.
> 3) This packet duly arrives at the client.
>
> OK - now to the code. I've tried every combination of socket connect &
> write, streams .. you name it ...but here are my two main variations:
>
>
> // Set up the connection ===================
> $remote_host = 'udp://192.168.1.126';
> $remote_port = 2934;
> $timeout = 1;
>
> // This is the outgoing msg (in hex) ==========
> $hello =
> "\x20\x00\x09\x42\x46\x4f\x31\x00\x00\x00\x00\x01\ x83\x05\x07\x0d\x12";
>
> // This part embeds the client's IP address (in hex, backwards!)
> // This is what the connecting flight sim appears to send
> $hello .="\x03\x01\xa8\xc0";
>
> // The rest of the data packet:- (sim version etc).
> $hello .= "\x03\x84\x0f\x87\x12\x02\x00\x00";
>
> // The returned data (I should be so lucky!) =====
> $ret = '';
>
> // Open the socket ================
> $socket = fsockopen($remote_host, $remote_port, $errno, $errstr,
> $timeout);
> if (!$socket) {
> echo "Connection Failed - Please check manually."; }
> else {
> // Send the packet ===
> fputs($socket, "$hello");
> // fputs($socket, "$hello\r\n"); // Try with a return? ===
>
> echo "Sent to $remote_host:$remote_port ";
>
> // So far so good ... the packet gets received
> // by the server (confirmed by sniffer) ...
> // and a reply gets sent to the client IP+port ..
>
> //... BUT ... neither of these appear to work =======
> //$ret = fgets($socket, 64);
> $ret = fread($socket, 2048);
> // Tried all sorts values from 1 to 2048 =====
>
> echo "[" . $ret . "]";
> fclose($socket);
> };
> echo "<hr>Closed";
>
> That's it! H-E-L-P !!! I wonder whether you/anyonecan shed any light
> on this!
>
> Adam.[/color]

Adam,

Let's back up a little. I'm wondering if we're looking at the wrong
problem.

A couple of thoughts here. First of all, where are you running the
sniffer? Is it on this machine, or somewhere upstream?

Also, are you using a firewall or a router anyplace? If so, are they
set up properly to pass the incoming data onto your program?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Mon, 26 Sep 2005 06:59:08 -0500, Jerry Stuckle wrote:
[color=blue]
>Adam wrote:[color=green]
>> Still no luck :-((
>>
>> I have Ethereal running on both client and server. Both versions
>> confirm that:
>>
>> 1) A request goes out to the server on port 2934. This is around 70
>> bytes: A header plus around 30 bytes of data.
>> 2) The server responds with a welcome of around 120 bytes.
>> 3) This packet duly arrives at the client.
>>
>> OK - now to the code. I've tried every combination of socket connect &
>> write, streams .. you name it ...but here are my two main variations:
>>
>>
>> // Set up the connection ===================
>> $remote_host = 'udp://192.168.1.126';
>> $remote_port = 2934;
>> $timeout = 1;
>>
>> // This is the outgoing msg (in hex) ==========
>> $hello =
>> "\x20\x00\x09\x42\x46\x4f\x31\x00\x00\x00\x00\x01\ x83\x05\x07\x0d\x12";
>>
>> // This part embeds the client's IP address (in hex, backwards!)
>> // This is what the connecting flight sim appears to send
>> $hello .="\x03\x01\xa8\xc0";
>>
>> // The rest of the data packet:- (sim version etc).
>> $hello .= "\x03\x84\x0f\x87\x12\x02\x00\x00";
>>
>> // The returned data (I should be so lucky!) =====
>> $ret = '';
>>
>> // Open the socket ================
>> $socket = fsockopen($remote_host, $remote_port, $errno, $errstr,
>> $timeout);
>> if (!$socket) {
>> echo "Connection Failed - Please check manually."; }
>> else {
>> // Send the packet ===
>> fputs($socket, "$hello");
>> // fputs($socket, "$hello\r\n"); // Try with a return? ===
>>
>> echo "Sent to $remote_host:$remote_port ";
>>
>> // So far so good ... the packet gets received
>> // by the server (confirmed by sniffer) ...
>> // and a reply gets sent to the client IP+port ..
>>
>> //... BUT ... neither of these appear to work =======
>> //$ret = fgets($socket, 64);
>> $ret = fread($socket, 2048);
>> // Tried all sorts values from 1 to 2048 =====
>>
>> echo "[" . $ret . "]";
>> fclose($socket);
>> };
>> echo "<hr>Closed";
>>
>> That's it! H-E-L-P !!! I wonder whether you/anyonecan shed any light
>> on this!
>>
>> Adam.[/color]
>
>
>Adam,
>
>Let's back up a little. I'm wondering if we're looking at the wrong
>problem.
>
>A couple of thoughts here. First of all, where are you running the
>sniffer? Is it on this machine, or somewhere upstream?[/color]

I've got Ethereal running on both machines:

1) Client: Linux - running the PHP script. No firewall.
2) Server: WinXP - running the sim in multiplayer mode. Firewall in
place (Norton PFW) but this server connects OK to other XP machines
running the sim in client mode.
[color=blue]
>Also, are you using a firewall or a router anyplace? If so, are they
>set up properly to pass the incoming data onto your program?[/color]

The router only sits between the network and the ADSL.

Anyway - I can *see* the packets leaving/arriving on each machine - so
I think the firewall thing is OK. The packets appear addressed
properly, and contain data.

Having done a fair bit of googling around, it seems PHP's sockets
implementation is a bit quirky. All sorts of oddities come into the
equation - the "magic_quotes" setting, stream_set_blocking and so on.

I could paste the dumps of each packet if that helps any.

Over to you, Mastah! <g>.

Adam.

Adam wrote:[color=blue]
> On Mon, 26 Sep 2005 06:59:08 -0500, Jerry Stuckle wrote:
>[color=green]
>>
>>Let's back up a little. I'm wondering if we're looking at the wrong
>>problem.
>>
>>A couple of thoughts here. First of all, where are you running the
>>sniffer? Is it on this machine, or somewhere upstream?[/color]
>
>
> I've got Ethereal running on both machines:
>
> 1) Client: Linux - running the PHP script. No firewall.
> 2) Server: WinXP - running the sim in multiplayer mode. Firewall in
> place (Norton PFW) but this server connects OK to other XP machines
> running the sim in client mode.
>[/color]

OK, since your client doesn't have a firewall, this shouldn't be a
problem. The reason I asked - if you have a firewall running on the
client, the packets may arrive at the client (and you might see them
with Ethereal), but they may be stopped before they get to the program.
[color=blue]
>[color=green]
>>Also, are you using a firewall or a router anyplace? If so, are they
>>set up properly to pass the incoming data onto your program?[/color]
>
>
> The router only sits between the network and the ADSL.
>
> Anyway - I can *see* the packets leaving/arriving on each machine - so
> I think the firewall thing is OK. The packets appear addressed
> properly, and contain data.
>[/color]

OK, as long as you can see the packets arriving at the client machine,
you should be OK. I was afraid you might be monitoring them on some
upstream system.
[color=blue]
> Having done a fair bit of googling around, it seems PHP's sockets
> implementation is a bit quirky. All sorts of oddities come into the
> equation - the "magic_quotes" setting, stream_set_blocking and so on.
>
> I could paste the dumps of each packet if that helps any.
>
> Over to you, Mastah! <g>.
>
> Adam.[/color]

I don't think the packet dumps will help any more than we already have.

As for the blocking mode - fsockopen() defaults to blocking mode, so the
fread() should block until some data comes in. And if the data do
arrive before you issue fread() (unlikely), the system should buffer it
until you issue fread().

However, this brings up another question. Does the fread() return
immediately, or is there a delay before it returns? I'm wondering if
it's possible that you are timing out on the fread() request. I'm not
sure what the default timeout value is (timeout on the fsockopen only
applies to making the connection) but you can use stream_set_timeout()
to set it to a longer value.

I really wish I could be more help here - but this is a problem I
haven't run into before.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Mon, 26 Sep 2005 13:11:20 -0500, Jerry Stuckle wrote:
[color=blue]
>OK, since your client doesn't have a firewall, this shouldn't be a
>problem. The reason I asked - if you have a firewall running on the
>client, the packets may arrive at the client (and you might see them
>with Ethereal), but they may be stopped before they get to the program.[/color]

Good thought. I hadn't considered the fact that a firewall could do
that. It's just possible that the firewall on the Linux box is
allowing *outgoing* traffic on 2934 but blocking *incoming*. I'll do
some digging around.
[color=blue]
>As for the blocking mode - fsockopen() defaults to blocking mode, so the
>fread() should block until some data comes in. And if the data do
>arrive before you issue fread() (unlikely), the system should buffer it
>until you issue fread().[/color]
[color=blue]
>However, this brings up another question. Does the fread() return
>immediately, or is there a delay before it returns? I'm wondering if
>it's possible that you are timing out on the fread() request. I'm not
>sure what the default timeout value is (timeout on the fsockopen only
>applies to making the connection) but you can use stream_set_timeout()
>to set it to a longer value.[/color]

Invariably, there's a delay. And this is for ALL types of socket read
that I try (simple fread or stream functions). Changing
stream_set_timeout() simply makes it sit there even longer - but in
many cases the whole script bombs out after 30 secs. Looking at the
ethereal output, that's around 29.999 secs too long <gg>.
[color=blue]
>I really wish I could be more help here - but this is a problem I
>haven't run into before.[/color]

My feeling is that it's to do with the "connection-less" state of UDP
- and that the incoming packet is *not* being buffered by PHP (or the
script has already "missed the boat"). All experiments with TCP work
as advertised.

Are there any simple UDP tests I could try? I found a [local]
time-server script but I don't think I have a time server service
running on that machine, so I got no output either.

In all my googling, I've seen very few comments to convince me that
anyone has actually had UDP sockets working - plenty of reports of
(early) bugs in PHP with sockets though.

Appreciate your input so far - thanks!

Adam.

On Mon, 26 Sep 2005 13:11:20 -0500, Jerry Stuckle wrote:
[color=blue]
>I really wish I could be more help here - but this is a problem I
>haven't run into before.[/color]

Jerry - success!!!

I finally got it working - but what an ordeal!!

1) It seems that socket support in PHP is "flakey" to say the least. I
followed a few of the bug threads on PHP.net - some seem to indicate
that old bugs have been re-inroduced in PHP5 :-(

2) A lot of the socket related functions don't work on the Win32 PHP
exes (probably because the socket support isn't "pre-compiled" <??>.

3) The documentation is really far from clear - particularly with
vital differences due to the "connection-less state" of UDP.

4) For the life of me I *still* can't get fread() to work - fwrite()
works fine.

Anyway - it shows that the firewall was never the problem.

So ... thanks for persevering with me!

Adam.

==========================
Here's the code:

Eventually, the script will loopo through a D/B query, but here's a
temporary loop through the 2 local test sim servers:

First the "hello" message gets sent:

$sites_array = array("192.168.1.20", "192.168.1.126");
foreach ($sites_array as $site_ip) {
$remote_IP = 'udp://';
$remote_IP .= $site_ip;
$portNumber = 2934;
$handle = fsockopen($remote_IP, $portNumber, $errno, $errstr,
2);
if (!$handle) {
echo "$errno : $errstr ";
}
socket_set_timeout ($handle, 2);
$write = fwrite($handle, $hello);
if (!$write) {
echo "OOPS! Error writing to port: $portNumber. ";
} else {
echo "Query sent to $remote_IP : $portNumber. ";
};
fclose($handle);

Then the read of the response (note the use of socket_set_option() to
set the time-out etc.). Also, socket_recvfrom() seemed to work as
well.

if (!$sock=socket_create(AF_INET,SOCK_DGRAM,SOL_UDP)) {
echo "Error: Failed to create socket,
".socket_strerror(socket_last_error($sock))." \ n";
} elseif (!socket_bind($sock,"0.0.0.0",2934)) {
echo "Error: Failed to bind socket,
".socket_strerror(socket_last_error($sock))." \ n";
socket_close($sock);
} else {
socket_set_option($sock,SOL_SOCKET,SO_REUSEADDR,1) ;
socket_set_option($sock,SOL_SOCKET,SO_RCVTIMEO,
array("sec"=>4, "usec"=>0));
//$size=socket_recvfrom($sock,$buf,65535,1,$clientIP ,$clientPort);
$buf=@socket_read($sock,2048);
if ($buf===FALSE) {
//echo "Error: Returned false,
".socket_strerror(socket_last_error($sock))." \ n";
echo "OFFLINE";
} else {
echo strlen($buf) . ":" . $buf;
}
echo "<hr>";
flush();
socket_close($sock);
}
};

======================

Adam wrote:[color=blue]
> On Mon, 26 Sep 2005 13:11:20 -0500, Jerry Stuckle wrote:
>
>[color=green]
>>I really wish I could be more help here - but this is a problem I
>>haven't run into before.[/color]
>
>
> Jerry - success!!!
>
> I finally got it working - but what an ordeal!!
>
> 1) It seems that socket support in PHP is "flakey" to say the least. I
> followed a few of the bug threads on PHP.net - some seem to indicate
> that old bugs have been re-inroduced in PHP5 :-(
>
> 2) A lot of the socket related functions don't work on the Win32 PHP
> exes (probably because the socket support isn't "pre-compiled" <??>.
>
> 3) The documentation is really far from clear - particularly with
> vital differences due to the "connection-less state" of UDP.
>
> 4) For the life of me I *still* can't get fread() to work - fwrite()
> works fine.
>
> Anyway - it shows that the firewall was never the problem.
>
> So ... thanks for persevering with me!
>
> Adam.
>[/color]

Hi, Adam,

Glad to see you got it going - but that was rough!

Sorry I wasn't of much help - you did great getting it to work!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

re: Ping+Port Routine?

Similar PHP bytes

/bytes/development

/bytes/it

/bytes/about