How can I find out whether a port on a remote system is accessible via UDP
or TCP?
You can't; you have to know. That's what "well-known" ports are all
about--a widely-observed convention as to what port numbers are
used for what common services. But it's just that--a convention.
Anyone can choose to run a web server on ports besides port 80,
and there's nothing the uninformed can do to find out about it except
to try to connect to every socket on a given host and, if you
get a connection, try sending a GET / HTTP/1.0 and see if it
responds meaningfully.
Does it matter if I use a TCP socket to connect to UDP port in php?
Depends on what you mean by "matter". As above, there's no harm
in trying (unless somebody at the host system thinks your running a
port scanner for some nefarious purpose, and blocks you IP for a while!)
But you won't succeed in connecting if you're not using the same
protocol.
If you are about to suggest to me to use the getprotobynumber
function, let me ask you this: What if on their system, ports have
different name?
Then they have to let you know this. For example, on a machine that
I'm setting up for an about-to-go-live web venture, there are at least
4 different ports that serve HTTP: port 80, which is the general web
server (and which uses the well-known port because we want
people to find it), port 443, for HTTPS (also well-known), another
high-numbered port running the Linux admin tool Webmin, and some
other port whose number I forget that the RealServer uses if it
needs to speak HTTP with somebody.
For example: I have a server broadcasting in UDP on port .... 3435.
If someone else were to create a PHP to connect to my port 3435,
can they know beforehand whether to use UDP or TCP
(without asking me)?
No.
When I set non-blocking on a socket, why can I not read any initial data?
There may not be any there yet. For example, if you were in non-blocking
mode, and connected to a webserver and said
GET / HTTP1.0\r\n\r\n
and then immediately issue a read() on the socket, it quite likely will
return with no data read because the server hasn't finished even finding
the file representing / on its hard drive yet! Non-blocking really is
non-blocking, and if you want to set a "reasonable" timeout you'll have
to track that yourself. Yes, this means a polling loop, with all the
terrible things that implies about CPU usage.
It's nice to see they've added the low-level socket functions, but
I notice that select() isn't among them. I've never really looked
at the internals of PHP; I wonder what it would take to add it?
