Thread: Getting Ip from socket.

but do i call getpeername before calling inet_ntoa()? because otherwise wouldn't the sockaddr struct be empty?
And, if this is the case then how is it possible because getpeername() will not accept a sockaddr_in struct, only sockaddr.
Basically, i have a socket, nothin else and i need to get the IP adress from it.

Why does the direct-connect'ing client have to listen on a different port than the server? They're not on the same machine, so you shouldn't run into a port conflict...

Well, the question asker said:

would they have to use another port from the one they were using to connect to the server?

If a client is currently using port X to connect to the server, then it could not use port X to connect to a client at the same time because that port is already in use. Now the client that is doing the listening could listen on the same port the server was listening on. Maybe I was just a little unclear on what Mr. Boolean was asking

how is it possible because getpeername() will not accept a sockaddr_in struct, only sockaddr.

Just cast the socketaddr_in to a sockaddr structure when you are passing it to getpeername().

I don't believe this is correct. You can connect to as many different servers as you want, using the same port (if you don't believe me, try it: Create a listening socket on port 22222, then create 5 sockets, and connect to 127.0.0.1 on port 22222 with each of them

I realize this is true, and I never said otherwise. What I said is that a client cannot connect to two different places using the same port. To use your example, lets say the client connects to the server (which is listening on port 22222) via port 10000. The client cannot make another connection to the server using port 10000, it must use a different port. Read what I said again a little more carefully

If a client is currently using port X to connect to the server, then it could not use port X to connect to a client at the same time because that port is already in use.

I think we have clarified that Hunter2 is talking about the destination port while bithub was referring to the source port. No need to hash it out any further (unless you want to, these threads are always entertaining for bystanders).

I was simply clarifying my previous posts because Hunter thought I was referring to something that I was not. If hunter understands what I was talking about now, then I am done (unless the thread starter still needs further clarifications).

thanks for all the help, i am now successfully getting the clients IP address.

>> Oh, great. So there's more than one kind? <<

Each connected socket has a source ip address and a source port as well as a destination ip address and destination port. These four bits of information are used by the socket provider to associate a packet with a connection.

Typically, the socket provider automatically selects the source ip address (most computers only have one ip address) and source port when you call connect(). This means that the source port and ip address is usually totally transparent to your program. You can retrieve the source ip address and port after a socket is connected using getsockname().

You can also specify the source port and ip address of a socket before you call connect() with a call to bind(). However, due to the possibility of conflicts this is strongly discouraged:

Originally Posted by MSDN

Binding to a specific port number other than port 0(ed's note: port 0 means use automatic selection) is discouraged for client applications, since there is a danger of conflicting with another socket already using that port number.

You can view source and destination information for current connections using the console command netstat -n. For example, this printout shows three connections from my computer to a website (actually a random ip address):

Code:

  Proto  Local Address          Foreign Address        State
  TCP    192.168.0.55:2824        99.143.76.204:80        ESTABLISHED
  TCP    192.168.0.55:2825        99.143.76.204:80        ESTABLISHED
  TCP    192.168.0.55:2826        99.143.76.204:80        ESTABLISHED

Note the different source ports. All other things being equal (source address, destination address, destination port), the socket provider uses the source port to differentiate between these connections.

When one refers to a port, in relation to sockets, they are usually, but not always, referring to the destination port. Hence the confusion.

sorry about this, i just have one more question that i just need your opinion on really.

So, the server is in a constant loop checking for new data on all of the sockets connected with a 10 millisecond pause, I would just like to know is this one loop enough to handle about 30 clients max? The clients can view other clients details that the server will read from a file, given the correct command and send them, they can send messages in a 'room', they can also send private messages to other clients that use //PM:: to tell the server it's a private message so it should only be sent to one client, They will soon be able to transfer files, And i just keep thinking is there anyway the clients could possibly send to much for the server to handle at once?

I am using the Select statement, it's just that i thought maybe a thread for each client would be a better idea.