Confusion over ports - comp.unix.programmer

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?

"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.

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.

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 ***

<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

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

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 ***

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

"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

In article <m3wtlf5fyw.fsf@invalid.address>, joe@invalid.address wrote: > "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. 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 ***

"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