Java Socket Constructor

[Lew]

This piece of documentation is incorrect. It doesn't pick a 'valid local
address', it picks INADDR_ANY. That's not what I would call a 'valid
local address' at all, it's the union of all local addresses.

Now that is being picky. The result of INADDR_ANY could be considered a
"valid local address" for the purposes of the class.

 

[Arne Vajhøj]

"bind"ing is (iirc) something quite different:
you wait for incoming connections with "bind"

Bind just "allocates" the port.

It is normal to use bind for server usage to specify
a specific port.

But you can use bind for client usage as well.

In fact I always do in my C code.

Arne

 

[Arne Vajhøj]

No, you should see *RFC793* and *RFC1192* for a description of the
protocol. Hobby pages can't possibly be a reliable source of
information.

I assume that he uses information collected from the net.

Just yesterday someone posted:

#> localhost is typically 127.0.0.1, which is the "loopback" address.
#
#Only on certain misconfigured Linux distributions. 'localhost' should
#be the first non-loopback IP address, not the loopback address.

....

Arne

 

[Lew]

I assume that he uses information collected from the net.

Just yesterday someone posted:

#> localhost is typically 127.0.0.1, which is the "loopback" address.
#
#Only on certain misconfigured Linux distributions. 'localhost' should
#be the first non-loopback IP address, not the loopback address.

Funny, but I could not corroborate that "information" with anything I found on
the 'net. /Au contraire/, I found plenty of corroboration that 'localhost'
does indeed map to the loopback address, including in the command 'man hosts'
on Linux.

So EJP has a point - it is wise to corroborate from authoritative sources, as
I assume Arne intended to show as well.

 

[Tim Smith]

information. Numerous errors I told this author about last year are are
still there:

'It [TCP] is a symmetrical peer to peer protocol'. It is a client-server
protocol.

That seems a bit picky. Connection establishment is not symmetrical,
but once the connection is established, it is symmetrical.

 

[EJP]

That seems a bit picky. Connection establishment is not symmetrical,
but once the connection is established, it is symmetrical.

Agreed, but what he actually writes is this:

'It is a symmetrical peer to peer protocol. Either client or server
could initiate the connection.'

 

[EJP]

I assume that he uses information collected from the net.

Does that matter?

Just yesterday someone posted:

Sure, I did indeed, but I also accepted correction, in the same place it
was posted, and also I didn't post it on a website entitled 'Java
glossary' and recommend it left right and centre as an authoritative
source ...

 

[John W. Kennedy]

Agreed, but what he actually writes is this:

'It is a symmetrical peer to peer protocol. Either client or server
could initiate the connection.'

It is still partly true, in FTP. And the case of X is notorious, where
the "client" is the server and the "server" is the client.

If you /define/ the "client" and the "server" according to the roles
they take in establishing the connection, why, then, yes, only the
"client" can initiate. But there are cases where insisting on this
terminology, once the connection is made, can lead to madness.

--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
....you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"

 

[Gordon Beaton]

And the case of X is notorious, where the "client" is the server and
the "server" is the client.

In X, the display is the server and the application is the client. The
client initiates the connection. What's notorious about that?

/gordon

--

 

[EJP]

If you /define/ the "client" and the "server" according to the roles
they take in establishing the connection, why, then, yes, only the
"client" can initiate. But there are cases where insisting on this
terminology, once the connection is made, can lead to madness.

I'm not insisting on it once the connection is made. I'm insisting on it
w.r.t. establishing the connection, since this is the context of the
original statement. Saying '... the server can initiate the connection'
is just nonsense for TCP. It can't. It can only accept it.

 

[Lew]

I'm not insisting on it once the connection is made. I'm insisting on it
w.r.t. establishing the connection, since this is the context of the
original statement. Saying '... the server can initiate the connection'
is just nonsense for TCP. It can't. It can only accept it.

To expand on that- to abuse the terminology and /not/ refer to the initiator
as "client" and the receiver as "server" is the way to madness. Engineering
disciplines require precision of expression. TCP is set up such that only one
end can initiate the connection - regardless of what you call it - as EJP
pointed out. By definition the end that must initiate is called the client.
John seems to say that there's something illegitimate about that. There isn't.

This business about

the case of X is notorious, where the "client" is the server and the "server" is the client.

is pure obfuscatory nonsense. Only one end of an X connection is the client,
and only that end gets to be called the client. Likewise for the other end
being the server. There is no "client is the server" going on at all. The
client is the client, and the server is the server. Gordon Beaton
straightened that one out. Don't be fooled by cute but totally inaccurate
rhetoric.

 

[Arne Vajhøj]

To expand on that- to abuse the terminology and /not/ refer to the
initiator as "client" and the receiver as "server" is the way to
madness. Engineering disciplines require precision of expression. TCP
is set up such that only one end can initiate the connection -
regardless of what you call it - as EJP pointed out. By definition the
end that must initiate is called the client.

I would say that I have seen client and server terms used in a
per layer basis.

Meaning that in X--Y then X can be client at the TCP level but
Y can be client at the application protocol level.

Arne

 

[Arne Vajhøj]

In X, the display is the server and the application is the client. The
client initiates the connection. What's notorious about that?

Often the X client is running on a box that is called server and
the X server is running in a box called client.

Arne

 

[Lew]

Often the X client is running on a box that is called server and
the X server is running in a box called client.

True, but not necessarily a case for notoriety.

The point that comes clear is that "client" and "server" definitions are
specific to the communication under discussion. The X client is the logic
server, but the X client is only a client in the context of the X communication.

One can get poetic, as JWK did about that, but the rhetorical device depends
on eliding the context shift between the channel devoted to application logic
and that devoted to graphical display.

Maybe it's the attempt to obfuscate via that elision that deserves to be
notorious.

 

[Arne Vajhøj]

Does that matter?


Sure, I did indeed, but I also accepted correction, in the same place it
was posted, and also I didn't post it on a website entitled 'Java
glossary' and recommend it left right and centre as an authoritative
source ...

Ah.

It is more OK to post wrong info to usenet than to put it on a web site.

Or ?

A couple of famous quotes:
* "He who is without sin among you, let him be the first to throw a
stone at her."
* "Treat others as you would like to be treated."

Arne

 

[Lew]

I would say that I have seen client and server terms used in a
per layer basis.

Meaning that in X--Y then X can be client at the TCP level but
Y can be client at the application protocol level.

Absolutely. The two points are complementary. The client at the TCP level is
by definition the initiator of the TCP communication. The client at the app
protocol level initiates app protocols.

By pointing out the importance of specifying to which layer the client-server
distinction applies, you have increased the precision of expression. That is
good engineering.

 

[John W. Kennedy]

To expand on that- to abuse the terminology and /not/ refer to the
initiator as "client" and the receiver as "server" is the way to
madness. Engineering disciplines require precision of expression. TCP
is set up such that only one end can initiate the connection -
regardless of what you call it - as EJP pointed out. By definition the
end that must initiate is called the client. John seems to say that
there's something illegitimate about that. There isn't.

This business about

is pure obfuscatory nonsense. Only one end of an X connection is the
client, and only that end gets to be called the client. Likewise for
the other end being the server. There is no "client is the server"
going on at all. The client is the client, and the server is the
server. Gordon Beaton straightened that one out. Don't be fooled by
cute but totally inaccurate rhetoric.

And FTP Active Mode dissappears in a puff of logic.

 

[Lew]

And FTP Active Mode dissappears in a puff of logic.

I think we're running into a layer issue here. As I understand FTP, the
"server" from the app standpoint is the one to whom requests are made. Active
and passive FTP are lower layer matters dealing with the network or transport, no?

 

[Martin Gregorie]

Absolutely. The two points are complementary. The client at the TCP
level is by definition the initiator of the TCP communication. The
client at the app protocol level initiates app protocols.

It seems to me that there's a more general way of looking at it:

A server advertises services for use by client processes. To do that it
MUST have a known address which clients go to in order the user the
services.

A client doesn't advertise anything and so doesn't need a known address.
There is no way that a client can provide a service because there is no
way to know its address until it contacts a server and starts to use the
service that the server provides.

This applies regardless of the transport protocol being used to carry
the service. It is fairly obvious in the case of TCP/IP because
connection is non-symmetric: the server MUST be listening for
connections, i.e. requests to the service it provides, but the client
never does. Other examples:

- in the *NIX world a server can listen to a named pipe to advertise an
service that's not available outside that host.

- An X.25 network is peer to peer in exactly the same way as POTS is,
but a service can't be used unless there's a process that's prepared
to accept incoming calls.

- 3270 bisync is the opposite: the entire transport protocol is
controlled by the server. If that's not running, the terminals
can't do anything.

- X-term fits the same pattern once you realize that an X server is
providing display and input services to an application program.
Another clue is that many applications can connect to a single X-term
server but no X-term can connect to even one application.

- FTP is the really strange case. When you start FTP, the user program
(client) connects its command channel to the daemon (server). Again,
the daemon advertises its service on a known host's port.

The confusion happens when a file transfer is requested because a new
data channel must be opened to shift the file contents before being
closed. If you're running in PASSIVE mode its the same: the server
returns a port number as part of its ACK and the user program connects
to that port, reads the data, and closes the port. No problem.
However, in classical mode the user program sends the daemon a port
that it wants to listen on and then becomes a server. The daemon acts
like a client and connects to the user program, sends the file and
closes the connection. Then both programs revert to their original
roles

By pointing out the importance of specifying to which layer the
client-server distinction applies, you have increased the precision of
expression. That is good engineering.

Agreed.

 

[John W. Kennedy]

I think we're running into a layer issue here. As I understand FTP, the
"server" from the app standpoint is the one to whom requests are made.
Active and passive FTP are lower layer matters dealing with the network
or transport, no?

FTP runs on two sessions, a command session and a data session. The
command session is initiated by the client; that part is easy. In
classic FTP, the data session is then initiated by the FTP server.
Because this nowadays typically causes firewall problems at the client,
a new "passive mode" FTP has been defined, in which, instead of
initiating the data session, the server requests the client, via the
command session, to initiate it, "active mode" being a retronym for the
original design. Passive mode must be requested explicitly, since not
all software supports it.

I don't know why they didn't just use a single session with a side
channel implemented in the data format in the first place, unless it was
simply to squeeze out the last drop of bandwidth.

So it may be technically correct to say, in describing how to program
for TCP, that it is always the client, by definition, that initiates the
session. But when explaining to someone who has just asked, "What is
TCP?", to whom "the server" means "the big box in the air-conditioned
room" and "the client" means "my PC", it is a pragmatic truth that "TCP
sessions may initiate with either the client or the server". To tell
him, "A TCP session always originates with the client," will only make
him believe a dangerous falsehood, and explaining the whole situation
runs the risk of making him go all Blanche DuBois on you ("My head is
swimming!"), at least in my experience.

If he needs to know more later, then we can say, "When setting up a TCP
session, the side that initiates it is always called the 'client', no
matter what happens after the session is set up." Anyone who needs to
know that will readily understand it.

--
John W. Kennedy
"Cricket is a game where you have 2 sides - one out in the field and the
other in, off the field. Each man in the side that is in, goes out, and
when he is out, comes in, and the next man goes out until he is out,
then he comes in. When the side that is in, goes out, they go in to get
the others which are in, out. Sometimes you get men still in, but not
out, but they are out. They go in when the side goes out, to be put in,
but not out. When both sides have been in and out, even those that are
not out, but also not in, that is the end of the game."
-- Anon.

--
John W. Kennedy
"There are those who argue that everything breaks even in this old dump
of a world of ours. I suppose these ginks who argue that way hold that
because the rich man gets ice in the summer and the poor man gets it in
the winter things are breaking even for both. Maybe so, but I'll swear I
can't see it that way."
-- The last words of Bat Masterson