This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Sockets and Internet Protocols and the fly likes server socket and accept call Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "server socket and accept call" Watch "server socket and accept call" New topic
Author

server socket and accept call

Monmohan Singh
Ranch Hand

Joined: Aug 02, 2002
Posts: 82
Sun's tutorial says that the accept call returns a socket with new port so that the server can still accept connections on the port to which it was bound ( eg port 80 for HTTP Server).
I went thru some material and a brief glance at Stevens book and could not find this thing elaborated.
an IP packet is represented by {protocol, source IP address, source port, destination IP address,
destination port}
and as long as one of this is different the packet can be differentiated .
also the packets will be in queue on the port where the server is listening..
Also in case of new port there can be issues with firewall?
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
i was confused by the same part of Sun's documentation. before reading that, i had always believed the difference between what Java calls a ServerSocket and the plain Socket that is returned by the accept() call was that the second has the other end's IP address associated with it where the first does not, and that this difference was enough to tell them apart. i honestly don't know what's right and what's wrong on this point; i guess i could find out with a little explorative coding, but right now i don't really care enough to do it.
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Think of the server socket like a receptionist. The receptionist has a public static phone number (port 80) that people call. When a call is received, the receptionist forwards the caller to the appropriate person so they can have a conversation. But the receptionist needs to continue answering calls on the original port, so the caller is forwarded to a new port, leaving the original free to receive more calls.

Since the router doesn't see this as a new incomming connection request, it typically lets it go.
Monmohan Singh
Ranch Hand

Joined: Aug 02, 2002
Posts: 82
"But the receptionist needs to continue answering calls on the original port, so the caller is forwarded to a new port, leaving the original free to receive more calls."

I don't think that this forwarding to new port happens.. because in this case when you look at the Socket created by accept call this should show a different value for the destination port which is not the case.
Also, what if firewall doesn't allow opening new ports on the machine?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Sure enough all the sockets handed out have the same local port. TCP is connection oriented, so it may be that the TCP layer of the stack maps the client connection to the new socket you get from ServerSocket.

Some protocols do open new ports. I think when an FTP client requests a connection and the server returns a new port number to use for the rest of the conversation. Some stateful firewalls are smart enough to observe the handshake and allow the new port, others just let the server open new FTP ports. Or not.

Wow, I thought I remembered more of this stuff. I'm going to have to dig into some old books for more details now.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8713
    
    6

Originally posted by Monmohan Singh:

I don't think that this forwarding to new port happens..

It does. Read the Java Tutorial Custom Networking Chapter if you don't believe Stan and I. How else could a server (meaning the software, not the comptuer) handle more than one connnection?


Also, what if firewall doesn't allow opening new ports on the machine?

Then network communications would not work. Firewalls distinguish between open (or listening) ports and those ports opened for use with established connections.


"blabbing like a narcissistic fool with a superiority complex" ~ N.A.
[How To Ask Questions On JavaRanch]
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
er, Joe, that tutorial you linked to is pretty much the one that had us confused and wondering in the first place. that text just doesn't sound right to me, because it seems to assume that TCP/IP uses only the port number as a distinguisher for connections. in contrast, it has always been my understanding that what's actually used is the full tuple of (source IP, source port, destination IP, destination port) -- after all, they're all unique numbers, so why not use them all?

unfortunately a quick google search found only one, slightly tangential, source to back up my contention -- this introduction to socket programming in Python implies that it works the way i was assuming it would.

more importantly, i just now wrote a client-server program pair to resolve the issue. with the server listening on port 7654, my client reported that after connecting successfully (and even reading a greeting from the socket), the client-side socket's .getPort() method said 7654, as if the server had not assigned it any new port number. and this is a multi-threaded server designed to accept multiple simultaneous clients, too.

on the server side, a .getPort() on the connected socket gives different port numbers for every new connection from the same machine. but i would expect that; the client program doesn't request any specific local port number when creating its socket to connect to the server, so the TCP/IP stack would just pick a handy one off the shelf, which seems to be what happens there.
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8713
    
    6

Originally posted by M Beck:
er, Joe, that tutorial you linked to is pretty much the one that had us confused and wondering in the first place.

Well crap. I was feeling so helpful. . .

Originally posted by M Beck:
that text just doesn't sound right to me. . . after all, they're all unique numbers, so why not use them all?

It's not a canonical guide to the TCP/IP protocol. We know that the network must use the IP address in order to identify the host. I don't think it matters what the OS or the VM uses to identify an individual socket. Sockets are an abstraction of network functionality. At an application level, which is where we are in object-oriented Java, we should not be concerned how they work, but rather their behavior. What the Java tutorial describes is the behavior (i.e. clear the server's bound socket and create a new one) and glosses over the implementation (which is something we can't control and can barely observe).


more importantly, i just now wrote a client-server program pair to resolve the issue. . . .

The client side socket doesn't need to know what the final socket is on the server side, so that is probably never communicated. Once the client side closes the connection, the socket can't be reconnected to that port. We'd have to create a new socket to the port the server is bound to. Again, what the client socket is reporting is not the implementation, but what the abstraction appears to be.
osman cinar eren
Ranch Hand

Joined: Jan 25, 2005
Posts: 78
hi,

this topic also confused me after I saw it in HFSJ. But this is not true. A connection(socket) between two machines are identified by 4 components: client IP, server IP, client port and server port.

The server accepts the new connection, creates a socket for this new connection, this socket has the local port 80.(for the http case) netstat verifies this and this is so.

i really wonder the reason of the saying in the SUN spec and HFSJ. How can we write such server applications?

regards.


SCJP/SCWCD
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

It's a flat-out mistake in the Sun tutorial; I wonder if the HF book didn't simply repeat the incorrect information from there. But yes, indeed, a TCP connection is identified by a unique quadruple of numbers: a port on each end, and an IP address on each end. As long as one of these four numbers differs, the TCP implementation can distinguish between two connections.


[Jess in Action][AskingGoodQuestions]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I had to go to Kurose & Ross on Computer Networking ...

During the three-way handshake, the client process knocks on the welcoming door of the server process. When the server "hears" the knocking, it creates a new door (that is, a new socket) that is dedicated to that particular client. ... [the server] calls WelcomeSocket's accept() method which creates a new ConnectionSocket.

Apparently the client socket is smart enough to switch over to the new "connection socket" as part of the connection handshake even though we can see no evidence of this by inspecting Java socket objects on either end.
osman cinar eren
Ranch Hand

Joined: Jan 25, 2005
Posts: 78
after i saw this,

Java makes socket programming extremely easy. To create a server listening for requests, all you need to do is create a ServerSocket object attached to a port number and call method accept(). For example, port 8080:

ServerSocket sSocket = new ServerSocket(8080);
Socket channel = sSocket.accept();

Method accept() returns when a client has connected to your server. The channel socket has a different port number than 8080. The server socket is 8080 so to get more than one person talking to the server at once, the server needs to hand off socket connections to a different port.

on the site; http://www.cs.usfca.edu/~parrt/course/601/lectures/sockets.html
, I decided to implement a basic server in Java:
ServerSocket sSocket = new ServerSocket(7777);
Socket channel = sSocket.accept();

while(true)
;

I made a telnet to 7777 and saw that the port number on the Server side of the established connection is 7777.

Everything is fine. There is no problem with Java, but Sun's reference.
Sameer Amte
Ranch Hand

Joined: Oct 22, 2002
Posts: 38
Stan's quote is spot on. I also had this confusion recently. The best way is to understand this ( in addition to reading etc) is to create client and a server and observe the flow of data using a packet sniffer like Ethereal/NetMon/snoop.
The above tools are very useful in monitoring network traffic and in understanding the grey areas of Networking.

Thanks
Sameer
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: server socket and accept call
 
Similar Threads
To know termenology
Socket on server side
Can I get source ip address and destination ip address of udp packet?
TCP/Socket mechanics of "Accept()" etc.
Question about ServerSocket port number and Socket port number