Home > Archive > Unix Programming > September 2005 > Confusion over ports
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Confusion over ports
|
|
| rishi.shah@patni.com 2005-09-16, 9:56 pm |
| Hello,
I am a newbie to socket programming and I had a doubt.
I have a server who is listening on Port x.
A client connects to the server using the connect command.
The server accepts the connection using the accept command.
Now a new socket file descriptor is returned and the structure
sockaddr_in is populated.
Now I wanted to know that the IP Address and the port contained in that
structure is that of the client or the server?
Also if I want some other client to connect to my original client than
will I have to listen on a new port separate from the port described
above?
| |
| Pascal Bourguignon 2005-09-16, 9:56 pm |
| "rishi.shah@patni.com" <rishi.shah@patni.com> writes:
> Hello,
>
> I am a newbie to socket programming and I had a doubt.
> I have a server who is listening on Port x.
> A client connects to the server using the connect command.
> The server accepts the connection using the accept command.
> Now a new socket file descriptor is returned and the structure
> sockaddr_in is populated.
> Now I wanted to know that the IP Address and the port contained in that
> structure is that of the client or the server?
This is the address and port of the remote party.
The address and port of the local port are known: you specified them
with bind(2). Well actually if you specified ANY as address, you can
find the actual local address with getsockname(2) to know at which
interface the incoming connection arrived.
> Also if I want some other client to connect to my original client than
> will I have to listen on a new port separate from the port described
> above?
No. You can accept several connections on the same port.
Have a look at the output of: netstat -tnp
You may see lines such as:
tcp 0 0 62.93.174.79:22 195.114.85.145:43809 ESTABLISHED -
tcp 0 0 62.93.174.79:22 62.93.174.79:34373 ESTABLISHED -
or:
tcp 0 0 62.93.174.79:33919 195.114.85.145:22 ESTABLISHED -
tcp 0 0 62.93.174.79:34342 195.114.85.145:22 ESTABLISHED -
showing how TCP sessions are established with two different
hosts:ports to the same local port, or just from two different local
ports to the same remote host:port.
(Of interest too might be: netstat -tnpl to see listening sockets)
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
| |
| rishi.shah@patni.com 2005-09-16, 9:56 pm |
| It is still not clear to me.
When the client connected to the server the client does not know about
its own port since the connect command requires the the server socket
information.
How do I get the client's port information.
After I get the client port information should I listen on this
port(this port was used for connecting to server) itself?
Should I not get another port for the client to listen?
I am first connecting to the server and then receving connections from
other clients.
| |
| Barry Margolin 2005-09-17, 4:03 am |
| In article <1126920732.086988.221650@z14g2000cwz.googlegroups.com>,
"rishi.shah@patni.com" <rishi.shah@patni.com> wrote:
> It is still not clear to me.
> When the client connected to the server the client does not know about
> its own port since the connect command requires the the server socket
> information.
The client normally just lets the system choose an unused port when it's
making the connection.
> How do I get the client's port information.
It's returned by accept(), or you can call getpeername() on the socket
returned by accept().
> After I get the client port information should I listen on this
> port(this port was used for connecting to server) itself?
No, the client port information is for the remote end.
> Should I not get another port for the client to listen?
> I am first connecting to the server and then receving connections from
> other clients.
What you don't seem to understand is that a TCP connection is identified
using the local and remote addresses and ports. So you can have
multiple connections to the same local port (the one that you listen
on), because they will be distinguished by the remote addrss and port
that was selected automatically by the connecting system.
Once accept() has returned, you don't have to do anything more. Just
send and receive on that socket, and you'll be talking to the client.
Call accept() again and you'll get another socket that allows you to
talk to another client.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2005-09-17, 4:03 am |
|
<rishi.shah@patni.com> wrote in message
news:1126920732.086988.221650@z14g2000cwz.googlegroups.com...
> It is still not clear to me.
> When the client connected to the server the client does not know about
> its own port since the connect command requires the the server socket
> information.
When you say "the client" do you mean the client application? It may or
may not know its own local IP and port. If it wants to, it can specify them
in a call to 'bind'. Otherwise, it's TCP/IP stack picks something sensible.
Either way, the client *machine* knows.
> How do I get the client's port information.
You get it when you call 'accept'. You can also call 'getsockname' and
'getpeername' at any time on an established TCP connection to get your
IP/port and the other side's IP/port.
> After I get the client port information should I listen on this
> port(this port was used for connecting to server) itself?
Huh? No, why would you do that?
> Should I not get another port for the client to listen?
> I am first connecting to the server and then receving connections from
> other clients.
Once the connection is established, it's established. Why do you think
you need to do anything else? Any number of clients can connect to the same
IP and port so long as they each connect *from* a different IP/port pair.
DS
| |
| rishi.shah@patni.com 2005-09-17, 9:56 pm |
| I think I understood the program flow
My client application first connects to server after the socket command
and connect command.
Now the client application can get is own port say PORT-X using which
it established the connection with the server application using
getsockname coomand
Now the client application can bind and listen on PORT-X
Now other clients can establish connections on this PORT-X
Code on the client application should look like this
sockfd = socket( ... )
Fill in the sockaddr_in structure with server application information
connect(...) // connect to server application
getSockName(...) // get the client own information(port and ip)
bind(...) // bind on the above port
listen(...) listen on the above port
accept (...) // wait for incoming connections
Please let me know if I am correct or if there is any better way
| |
| Barry Margolin 2005-09-17, 9:56 pm |
| In article <1127002992.382843.71930@g47g2000cwa.googlegroups.com>,
"rishi.shah@patni.com" <rishi.shah@patni.com> wrote:
> I think I understood the program flow
> My client application first connects to server after the socket command
> and connect command.
> Now the client application can get is own port say PORT-X using which
> it established the connection with the server application using
> getsockname coomand
> Now the client application can bind and listen on PORT-X
> Now other clients can establish connections on this PORT-X
> Code on the client application should look like this
>
> sockfd = socket( ... )
> Fill in the sockaddr_in structure with server application information
> connect(...) // connect to server application
> getSockName(...) // get the client own information(port and ip)
> bind(...) // bind on the above port
> listen(...) listen on the above port
> accept (...) // wait for incoming connections
>
> Please let me know if I am correct or if there is any better way
I don't understand what you're doing. Why would someone connect to the
client? Clients connect to servers, not the other way around. Is this
some kind of peer-to-peer application?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| rishi.shah@patni.com 2005-09-17, 9:56 pm |
| Yes it is a peer to peer type application in which server is the
listener controlling and monitoring the network and each client
application form a mesh.
Hence each client application has to connect to other client appications
| |
| joe@invalid.address 2005-09-17, 9:56 pm |
| "rishi.shah@patni.com" <rishi.shah@patni.com> writes:
> I think I understood the program flow
> My client application first connects to server after the socket
> command and connect command. Now the client application can get is
> own port say PORT-X using which it established the connection with
> the server application using getsockname coomand Now the client
> application can bind and listen on PORT-X Now other clients can
> establish connections on this PORT-X Code on the client application
> should look like this
Don't do it like that. Have each client establish a well-known port to
listen for other clients on. Assuming one client per machine, you can
use the same port for each client. In the case the "client" are both
client and server.
> sockfd = socket( ... )
> Fill in the sockaddr_in structure with server application information
> connect(...) // connect to server application
> getSockName(...) // get the client own information(port and ip)
> bind(...) // bind on the above port
> listen(...) listen on the above port
> accept (...) // wait for incoming connections
Since the client isn't binding a specific port, it gets an ephemeral
port from the OS. Other clients won't know what that port is, so they
won't know what to connect to.
Just establish a "server" port for the main server, and a "client
server" port for all the clients.
Joe
--
I never veer to starboard 'cuz I never sail at all
- The Pirates Who Don't do Anything
| |
| Barry Margolin 2005-09-19, 3:56 am |
| In article <m3wtlf5fyw.fsf@invalid.address>, joe@invalid.address wrote:
> "rishi.shah@patni.com" <rishi.shah@patni.com> writes:
>
>
> Don't do it like that. Have each client establish a well-known port to
> listen for other clients on. Assuming one client per machine, you can
> use the same port for each client. In the case the "client" are both
> client and server.
The "one client per machine" assumption can be a problem on multi-user
machines, if two users want to run the application at the same time.
If you don't want to have this limitation, the application should create
a second socket, and call bind() with 0 as the port. The stack will
find an unused port and bind it, and you can then use getsockname() to
find out what port it is. The client application should then send this
port to the server, and it can tell other clients what port you're
listening on.
Note that there's no relationship between this port and the port used
when connecting to the server.
One problem you're likely to run into with this type of application is
that it won't work on client machines behind NAT routers. The router
won't know to forward this port to the client machine.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2005-09-19, 6:58 pm |
|
"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-6D0CCE.00075019092005@comcast.dca.giganews.com...
> One problem you're likely to run into with this type of application is
> that it won't work on client machines behind NAT routers. The router
> won't know to forward this port to the client machine.
There are a few ways to work around this. One way is to make sure that
either client can initiate the connection. That way, as long as one client
isn't behind such a device, the two can talk to each other. The server would
have to tell one machine the IP and port to connect out to. Another option
is to have the server act as a relay for cases where neither client can
connect out.
Ideally, your application would be able to work even if both clients can
only make an outbound TCP connection to the server on its well known port.
However, you can certainly support UDP direct client-to-client in cases
where it works. Generally you try what works best for your application first
and fall back to what works given the network setup.
DS
|
|
|
|
|