TCPServer

[David Corbin]

Why is TCPServer inheriting from TCPSocket? What methods on it might be used
other than accept, and close?

David

 

[Eric Hodel]

--Apple-Mail-1-521292712
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Why is TCPServer inheriting from TCPSocket? What methods on it might
be used
other than accept, and close?

A TCP Server is just a socket you called listen(2) on:

To accept connections, a socket is first created with socket(2), a
will-
ingness to accept incoming connections and a queue limit for
incoming
connections are specified with listen(), and then the connections
are
accepted with accept(2). The listen() call applies only to
sockets of
type SOCK_STREAM or SOCK_SEQPACKET.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-1-521292712
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCR1qEMypVHHlsnwQRAm6dAKCQlgH1jlgRVKZVBnLxUF6KW4j2/gCeMFiB
sS+iB54EbFZQ1wdtPLkX+hw=
=+WBb
-----END PGP SIGNATURE-----

--Apple-Mail-1-521292712--

 

[David Corbin]

A TCP Server is just a socket you called listen(2) on:

To accept connections, a socket is first created with socket(2), a
will-
ingness to accept incoming connections and a queue limit for
incoming
connections are specified with listen(), and then the connections
are
accepted with accept(2). The listen() call applies only to
sockets of
type SOCK_STREAM or SOCK_SEQPACKET.

Exactly my point. So why does it inherit from TCPSocket, and more importanly
IO? read, write and all the variations are all not applicable, as far as I
can tell.

David

 

[Yukihiro Matsumoto]

Hi,

In message "Re: TCPServer"

|Exactly my point. So why does it inherit from TCPSocket, and more importanly
|IO? read, write and all the variations are all not applicable, as far as I
|can tell.

Just for implementation simplicity, rather than purity.

matz.

 

[Yohanes Santoso]

Exactly my point. So why does it inherit from TCPSocket, and more importanly
IO? read, write and all the variations are all not applicable, as far as I
can tell.

Exactly because it is a TCPSocket. A TCPServer is a TCPSocket with
bound local address(es) (whether it is a specific local address or all
addresses the local host responds to) and thus can be made to listen
to incoming TCP connections on those _bound_ local address(es).

YS.

 

[Kero]

Why is TCPServer inheriting from TCPSocket? What methods on it might

Exactly my point. So why does it inherit from TCPSocket, and more importanly
IO? read, write and all the variations are all not applicable, as far as I
can tell.

select() works on it, iirc.

+--- Kero ----------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+

 

[David Corbin]

Exactly because it is a TCPSocket. A TCPServer is a TCPSocket with
bound local address(es) (whether it is a specific local address or all
addresses the local host responds to) and thus can be made to listen
to incoming TCP connections on those _bound_ local address(es).

Is it really a TCPSocket, or is it just a TCP socket. If it's a TCPSocket, I
could do this.

socket = TCPServer('www.google.com', 80)
socket.puts "GET /"

etc. It's not that I think I can't do that (it might actually work for all I
know), but I can't imagine why I would to.

 

[Saynatkari]

Is it really a TCPSocket, or is it just a TCP socket. If it's a TCPSocket, I
could do this.

socket = TCPServer('www.google.com', 80)
socket.puts "GET /"

etc. It's not that I think I can't do that (it might actually work for all I
know), but I can't imagine why I would to.

I don't understand what the deal is here. This is how standard
sockets work. A server is, literally, a socket that's listen()ing
for connections: its input consists of connection requests. In
addition to that, since it's a socket, a server must call socket()
to establish itself, just like a 'client' socket. Therefore it
makes sense for a TCPServer to be a TCPSocket (without it, one
would establish a server by calling TCPSocket#listen). Is this
separation of responsibility causing problems for you?

E

 

[Eric Hodel]

Is it really a TCPSocket, or is it just a TCP socket. If it's a
TCPSocket, I
could do this.

socket = TCPServer('www.google.com', 80)
socket.puts "GET /"

Would that make sense for the UNIX implementation of sockets? No.

You'll probably get an ENOTCONN back because you haven't connected your
socket to anything.

etc. It's not that I think I can't do that (it might actually work
for all I
know), but I can't imagine why I would to.

Then why do you care?

Like a Socket you can call:

#addr, #getsockopt, #setsockopt, #shutdown

You can also IO::select a server socket.

Like an IO you can call:

#fcntl, #close, #close_read, #close_write, #closed?, #fileno

I think that's more than enough reason to make it a subclass of
TCPSocket, rather than try to break the shared functionality of regular
sockets and server sockets (and IOs) into common code only to recombine
them again.

I'd rather use some handwavium and subclass. Sounds far more
convenient.