TCPSocket error

Hi all,

I am a student learning ruby and I am getting an error that I can’t
figure out. It works on my teacher’s mac, however does not on my laptop.

Windows Vista 64-bit
My ruby version is: 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

Here is what I’ve tried in cmd

irb

irb(main):002:0> require ‘socket’
=> true
irb(main):005:0> TCPSocket.open(‘0.0.0.0’, 8888)
Errno::EADDRNOTAVAIL: The requested address is not valid in its context.

  • conne
    ct(2)
    from (irb):5:in initialize' from (irb):5:inopen’
    from (irb):5
    from C:/Ruby19/bin/irb:12:in `’

Any help would be appreciated!

On Jun 2, 2010, at 4:08 PM, Ted P. wrote:

ct(2)
from (irb):5:in initialize' from (irb):5:in open’
from (irb):5
from C:/Ruby19/bin/irb:12:in `’

Any help would be appreciated!

Posted via http://www.ruby-forum.com/.

Is there a server listening at port 8888?

server = TCPServer.new(‘0.0.0.0’, 8888)

There’s some examples in the Programming Ruby book from the Pragmatic
Publishers.

-Rob

Rob B.
http://agileconsultingllc.com
[email protected]

[email protected]

On 6/2/10, Ted P. [email protected] wrote:

    from (irb):5
    from C:/Ruby19/bin/irb:12:in `<main>'

Any help would be appreciated!

Apparently, 0.0.0.0 is treated as a loopback address on the mac. Apple
got this wrong; that’s a broadcast address and should be treated as
the same as 255.255.255.255. 127.0.0.1 is the canonical loopback
address, and that’s what you should use for greatest portability.

Ted P. wrote:

irb(main):002:0> require ‘socket’
=> true
irb(main):005:0> TCPSocket.open(‘0.0.0.0’, 8888)
Errno::EADDRNOTAVAIL: The requested address is not valid in its context.

Like it says, 0.0.0.0 is not a valid destination IP address. Try
instead:

TCPSocket.open(‘127.0.0.1’, 8888)

Brian C. wrote:

Ted P. wrote:

irb(main):002:0> require ‘socket’
=> true
irb(main):005:0> TCPSocket.open(‘0.0.0.0’, 8888)
Errno::EADDRNOTAVAIL: The requested address is not valid in its context.

Like it says, 0.0.0.0 is not a valid destination IP address. Try
instead:

TCPSocket.open(‘127.0.0.1’, 8888)

Dunno why, but ruby on linux seems to let me connect to 0.0.0.0. A
socket bound to 127.0.0.1 does seem to accept this connection.

Caleb C. wrote:

Here is what I’ve tried in cmd
from (irb):5:in open' from (irb):5 from C:/Ruby19/bin/irb:12:in

Any help would be appreciated!

Apparently, 0.0.0.0 is treated as a loopback address on the mac. Apple
got this wrong; that’s a broadcast address and should be treated as
the same as 255.255.255.255. 127.0.0.1 is the canonical loopback
address, and that’s what you should use for greatest portability.

IIUC 0.0.0.0 is the default route, not a broadcast addr. If you bind a
tcp server to 0.0.0.0, then you can accept connections from any
interface. I didn’t know you could use this on the client side, too.

On Thu, Jun 3, 2010 at 4:08 AM, Ted P. [email protected] wrote:

I am a student learning ruby

welcome :slight_smile:

and I am getting an error that I can’t
figure out. It works on my teacher’s mac, however does not on my laptop.

teachers are always ready :wink:

Windows Vista 64-bit
My ruby version is: 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

ok

Here is what I’ve tried in cmd
irb
irb(main):002:0> require ‘socket’
=> true
irb(main):005:0> TCPSocket.open(‘0.0.0.0’, 8888)
Errno::EADDRNOTAVAIL: The requested address is not valid in its context.

  • connect(2)

hint. you need a pair :wink:
you are trying to connect as a client to a server ip 0.0.0.0 thru port
8888
you’ll need another server running on your host at 0.0.0.0 thru port
8888
note 0.0.0.0 as client and server is only accessible locally, ergo
your client and server will treat you as local 127.0.0.1 (0.0.0.0 is
just a def gw ip wc in this case, will route you to local 127.0.0.1)

eg,

$ script/server -p 8888
=> Booting Mongrel
=> Rails 2.3.8 application starting on http://0.0.0.0:8888
=> Call with -d to detach
=> Ctrl-C to shutdown server

Processing Rails::InfoController#properties (for 127.0.0.1 at
2010-06-03 12:27:51) [GET]
SQL (0.8ms) SELECT name
FROM sqlite_master
WHERE type = ‘table’ AND NOT name = ‘sqlite_sequence’

Completed in 227ms (View: 17, DB: 1) | 200 OK
[http://0.0.0.0/rails/info/properties]

s=TCPSocket.open(‘0.0.0.0’, 8888)
=> #<TCPSocket:fd 5>
s.peeraddr
=> [“AF_INET”, 8888, “127.0.0.1”, “127.0.0.1”]

kind regards -botp

Robert K. wrote:

  1. 0.0.0.0 cannot be used as a valid address to connect to - you get
    EADDRNOTAVAIL as shown above.

What surprised to me is that you can connect to 0.0.0.0. (It’s not
surprising that the connection actually goes to 127.0.0.1.)

Try it on linux:

shell 1

$ ruby -rsocket -ve ‘puts TCPServer.open(“0.0.0.0”, 8888).accept.gets’
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
hello, world
$

shell 2

$ ruby -rsocket -ve ‘TCPSocket.open(“0.0.0.0”, 8888).puts “hello,
world”’
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
$

Also, this shows it’s not just a ruby thing:

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.038 ms

On 03.06.2010 04:31, Joel VanderWerf wrote:

     from (irb):5:in `initialize'

IIUC 0.0.0.0 is the default route, not a broadcast addr. If you bind a
tcp server to 0.0.0.0, then you can accept connections from any
interface. I didn’t know you could use this on the client side, too.

But you just said that it’s the default route, which is something used
by a client. I don’t have my Stevenson handy but IIRC the situation is
like this:

  1. 0.0.0.0 when used to bind a server socket is a wildcard for “all
    interfaces”, which means whichever IP is used to address this host the
    socket will listen. In contrast if you bind to 127.0.0.1 you can only
    connect from the local machine.

irb(main):001:0> srv = TCPServer.new ‘0.0.0.0’, 33445
=> #TCPServer:0x104f6400
irb(main):002:0> srv.close
=> nil
irb(main):003:0> srv = TCPServer.open ‘0.0.0.0’, 33445
=> #TCPServer:0x106d00c8
irb(main):004:0> srv.close
=> nil

  1. 0.0.0.0 cannot be used as a valid address to connect to - you get
    EADDRNOTAVAIL as shown above. Broadcast addresses have all bits of the
    host part set and consequently typically end in .255:
    Broadcast address - Wikipedia
    IP address - Wikipedia

I’d say, if this is possible on a Mac then Apple (or BSD) is doing
something weird here and probably not according to the specs.

  1. In routing tables it denotes the default route and is used with
    netmask 0:
    0.0.0.0 - Wikipedia

Kind regards

robert

On Thu, Jun 3, 2010 at 11:56 PM, Joel VanderWerf
[email protected] wrote:

What surprised to me is that you can connect to 0.0.0.0. (It’s not
surprising that the connection actually goes to 127.0.0.1.)

that is ok.
receivefr 0.0.0.0 (aka INADDR_ANY) will work for any addr (cause
that’s what it’s used for)
sendto 0.0.0.0 will work only for loopback (for obvious reasons :slight_smile:

kind regards -botp

On 6/3/10, Joel VanderWerf [email protected] wrote:

Robert K. wrote:

  1. 0.0.0.0 cannot be used as a valid address to connect to - you get
    EADDRNOTAVAIL as shown above.

What surprised to me is that you can connect to 0.0.0.0. (It’s not
surprising that the connection actually goes to 127.0.0.1.)

Try it on linux:

Huh. I find this surprising too.

So, I went and looked up chapter and verse of what the standard
actually says about this address. rfc 1812, the router requirements
rfc, lists 0.0.0.0 as primarily meaning ‘this host’, (section
4.2.2.11) but also says it has a nonstandard, obsolete meaning of the
all hosts broadcast address (but 255.255.255.255 is be be preferred)
(section 4.2.3.1). I was not aware of the first meaning; I just
thought it was a funky form of broadcast address. So I guess linux and
mac are correct in treating it like a loopback address.

Rfc 1812 talks about ‘routers’, but presumably what it says applies
generally to hosts, where it doesn’t deal directly with routing. I
couldn’t find anything relevant in the host requirements rfc (rfc
1123), or the rfc for ip itself (rfc 791), so presumably what 1812
says on this is as close to gospel as it gets.