I have been googling for about two hours to solve problem with sockets
connect method. I need to check connection to server www.example.com:xxxx (UDP)
but the problem is that the answer (connected, refused or smth…)
returns only with @socket.print “smth” + @socket.recv. (@socket.connect
only takes the port and address for using when @socket.print is called)
The problem is that I don’t know what I should print there. I just need
to check the connection.
In PHP there are very simple solution:
$fp = fpsockopen(…)
if ($fp) return true; else return false;
and just then you can send and receive data.
Maybe there are any solutions within sockets?
Well, I was trying this but it returns the same response when it’s
possible to connect to IP but not to port (example: port 1234 not binded
in server but the response is the same as with binded port 80)
Well, I was trying this but it returns the same response when it’s
possible to connect to IP but not to port (example: port 1234 not
binded
in server but the response is the same as with binded port 80)
UDP is connectionless, unreliable, and will not report errors to you
for foreign “connections”. I am unsure as to why the api is like it
is, other than that it follows iirc, the bsd sockets api.
I know there’s a connect method, but that is merely for convenience.
Look at UDP(4) (that is, man 4 udp).
The only reason you would be getting strange errors is if you’re
testing over localhost. Errors for UDP packets are irregular at best:
Thank you for replay. Well, in PHP there is a function which works fine
(fsockopen) so I need function in ruby working in the same way as that
function in PHP.
I can see a lot of strange responses and so on but I still need the
solution
i think you just want to check a udp connection to a udp server. no
problem.
require ‘socket’
s = UDPSocket.new
s.connect(“10.10.10.10”, 10101)
puts “you are connected” #<-- if you get here, you are connected
when I trying to connect with PHP (fsockopen) it fails: Warning:
fsockopen() [function.fsockopen]: unable to connect to xxx.xx.xx.xx:2555
(No route to host)
The problem is that I don’t know what I should print there.
I just need to check the connection.
In PHP there are very simple solution:
$fp = fpsockopen(…)
if ($fp) return true; else return false;
i think you just want to check a udp connection to a udp server. no
problem.
require ‘socket’
s = UDPSocket.new
s.connect(“10.10.10.10”, 10101)
puts “you are connected” #<-- if you get here, you are connected
the reason the above works is that s.connect will raise an exception if
it cannot connect and you’ll have to catch the reason by rescue-ing it.
and just then you can send and receive data.
Maybe there are any solutions within sockets?
socket programming in ruby is very complete and ranges from low level
basic socket programming to high level uri… you might want to read the
ruby programming language book…
when I trying to connect with PHP (fsockopen) it fails: Warning:
irb(main):003:0> s.connect(‘xxx.xx.xx.xx’, 2555)
=> 0
irb(main):004:0> puts ‘ok’
ok
=> nil
I think this example really shows the problem about which I am talking
All that is doing, is checking that the IP is routable. Nothing more.
This has nothing to do with the port availability or providing you
with any information as to whether or not the application is
available at the other end. Please carefully read my other responses
and the referenced manuals and documentation.
if it cannot connect and you’ll have to catch the reason by rescue-
ing it.
Interesting idea, however, as I said in my last post, this is really
not possible to do reliably with UDP (in fact, at all in reality, as
the api will “lie”). UDP is stateless and connectionless, there are no
connections. The PHP api was essentially lying to the OP, and ruby
will too (in fact, it’s not a lie, it’s PEBKAC, and the man page for
UDP(4) will explain what I’m telling you guys better than I have,
please do read it):
require ‘socket’
=> true
sock = UDPSocket.new
=> #UDPSocket:0x8320c
sock.connect(‘some.really.long.domain.that.doesnt.exist’, 1234)
SocketError: getaddrinfo: nodename nor servname provided, or not known
from (irb):3:in connect' from (irb):3 from :0 sock.connect('127.0.0.220',1234) # Please note carefully that this IP does not exist, and there's no machine on it. => 0 ping -c 1 127.0.0.220`
=> “PING 127.0.0.220 (127.0.0.220): 56 data bytes\n\n— 127.0.0.220
ping statistics —\n1 packets transmitted, 0 packets received, 100%
packet loss\n”
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
N.N.B. No failures, at all, and yet there should be if there was a
sock.connect(‘192.168.253.253’, 1234) # Please note carefully that
this IP does not exist, and there’s no machine on it.
=> 0
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
Still no failures…
sock.connect(‘67.207.151.240’, 1234) # Please note carefully that
this IP does not exist, and there’s no machine on it I think. See
note at end of mail.
=> 0
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
sock.write(‘foo’)
=> 3
Both of the above “connections” should have “failed” (they don’t
because there are no connections, and there are no ‘failures’ for UDP,
the protocol is dumb as hell and will never know, unless the packets
are actively rejected by a host at the receiving IP address), there
are no machines on those IPs. I’ve provided multiple examples on
different ip classes and you’ll notice that the DNS error is a DNS
error, not a UDP socket connect. UDP doesn’t “connect”.
I have since looked up why the “connect()” function even exists, and
it is for the sole purpose of reserving a source port for sending data
(which may aid in remote stateful logic, where the application layer
protocol is not completely stateless, even though UDP is).
and just then you can send and receive data.
Maybe there are any solutions within sockets?
socket programming in ruby is very complete and ranges from low
level basic socket programming to high level uri… you might want
to read the ruby programming language book…
And I’ll repeat, please read UDP(4).
That is man 4 udp. Other good references can be found on wikipedia:
It’s very very important that the OP realises that their code in
whatever language, is not doing what they think.
kind regards -botp
P.S. The last IP, the one that’s internet public I chose by searching
for an IP that didn’t respond to ICMP echo, so it may actually exist,
nonetheless, it was the first empty publicly routable IP I could find
that appeared to be down, without actually doing a massive scan range
over the internet (which is frowned upon). Please don’t abuse that IP,
I don’t know who it belongs to, nor do I care at this point.
Thank you for all replays. Now everything is more clear. In php manual:
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 in conclusion there is no way to check that UDP port is working or
not? Maybe there is a common query which you can send by UDP and then
receive any response?
Hi,
----- Original Message -----
From: “Kr Alfabeta” [email protected]
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” [email protected]
Sent: Thursday, April 17, 2008 8:58 PM
Subject: Re: checking connection to server:port
not? Maybe there is a common query which you can send by UDP and then
receive any response?
Try this:
require ‘timeout’
require ‘socket’
port = 1000
server = ‘127.0.0.1’
s = UDPSocket.new
s.connect(server,port)
s.write("\0")
begin
Timeout.timeout(1){s.read}
rescue Errno::ECONNREFUSED => e
puts "closed"
rescue Timeout::Error
puts "open"
ensure
s.close
end
Thank you for all replays. Now everything is more clear. In php
manual:
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.
Typical.
This is wrong. “connectionless” needs no quotes, it is
connectionless. The operating system never ever “establishes a link”
with UDP. It merely constructs a UDP packet and passes it to the
appropriate next-hop router (or the target ip if on the same subnet),
and forgets about it. There is no link, there is no connection. With
UDP there never will be. That’s the point of the protocol.
So in conclusion there is no way to check that UDP port is working or
not? Maybe there is a common query which you can send by UDP and then
receive any response?
No, you can check for a particular response if the application
protocol is designed to send one, or you can be lucky and the target
IP address will actively refuse the packet, in which case you get
some notification back on some systems. This is not complete
‘checking’ for a working application, at all. If the box goes
completely offline, and there are no devices doing anything outside of
the UDP protocol spec, then you’ll get no notification of the failure
to deliver. Nothing, nada, complete silence.
A timeout solution waiting for a response may be appropriate for certain application level protocols from which you might expect a
response to your packets, however, this is really completely not the
purpose of UDP.
Why are you trying to check that a UDP port is open? And if you need
reliable communications you should be using TCP.
On Thu, Apr 17, 2008 at 7:58 AM, Kr Alfabeta [email protected] wrote:
So in conclusion there is no way to check that UDP port is working or
not? Maybe there is a common query which you can send by UDP and then
receive any response?
There is no query/response in UDP. It’s fire-and-forget. The only
way you can get a “response” is if you control the receiving computer
and can put some code on it to fire a message back to a receiving port
on the sender after it receives a message. Of course, in UDP there’s
no guarantee that the reply will arrive…
Having once implemented a reliable multicasting protocol on top of UDP
(long story), I can say this: don’t try to treat UDP as a
connectional protocol unless you have a really, really good reason.
That’s what TCP is for.
I think this example really shows the problem about which I
am talking
mea culpa. you’re right. ruby does indeed implems basic udp, nothing
more, nothing less. Reading the ruby book, the udp#connect method just
saves the target and port for #send. So udp#connect is not really a
connect.
if you want a confirmation or a real connect, you need TCPSocket since
it does a handshake to connect or implem icmp or handshake-like protocol
using udp.
eg,
irb(main):095:0> t=TCPSocket.new “10.2.10.1”,80
=> #TCPSocket:0xb7de652c
irb(main):096:0> t=TCPSocket.new “10.2.10.11”,80
Errno::EHOSTUNREACH: No route to host - connect(2)
s.connect(server,port)
s.write("\0")
begin
Timeout.timeout(1){s.read}
rescue Errno::ECONNREFUSED => e
puts “closed”
Tells you a machine received it (hopefully the real one ), and that
the port was not open when the packet was received. You do not know
when that was, or which packet it was.
rescue Timeout::Error
puts “open”
Tells you that the machine did no actively refuse it, and nothing
else. Many strictly configured firewalls will result in this for all
UDP ports, at which point you really know nothing at all form this
result, and it’s highly likely they’re all closed in reality, with the
default rule being:
irb(main):095:0> t=TCPSocket.new “10.2.10.1”,80
=> #TCPSocket:0xb7de652c
irb(main):096:0> t=TCPSocket.new “10.2.10.11”,80
Errno::EHOSTUNREACH: No route to host - connect(2)
Thank you for help guys! The specification of product says that
“connection” available through UDP but you can check the connection
using TCP… interesting… Anyway, thanks!
), and that