Getting Ip from socket.

ok.
I have clients that connect to a server, i need the server to some how get the clients ip address so that i can pass them to other clients so i can allow direct connections of clients.
For example, clientA connects to the server and clientB also connects to the server. clientA tells the server that he wants to send a file to clientB. So the server needs to do something like GetIpFromSocket(clientAsocket) and then send that to clientB so that both clients can achieve a direct connection. Any help on this matter will be apreciated.

thanks in advance.

accept() will return the ip address. Alternatively, getpeername() can retrieve the remote ip address of a connected socket.

You need to be aware that many/most clients will be behing firewalls and you will not be able to connect to them without configuration by the user (which they will be very reluctant to perform).

Sounds like P2P app. What the guy above said is true, so you may need to do some work with your Applications protocol, to determine if some one can connect directly, you may have too do some odd ball stuff to get the connection, like having a request system in your protocol that asks the which one can accept connections, and then tell the other one to connect to the one that can. Sorry that may sound confusing.

hmm, i never thought of that, it could and will be quite a problem.
I also don't see anyway around it without the user configuring his/her firewall.
Do either of you know how a direct connection between clients could be achieved without disturbing the firewall?
programs like msn messenger do it.

Quote:

---

Do either of you know how a direct connection between clients could be achieved without disturbing the firewall?

---

Nope. Any firewall that allowed another computer to connect to it without any sort of configuration would be pretty worthless, wouldnt it?

Quote:

---

programs like msn messenger do it.

---

No, msn messenger doesnt do it. What it does is have client A try to connect to client B. If it cant, then it will have client B try to connect to client A. If they are both behind a firewall, then it cant send the file without one of the clients doing some configuration.

Quote:

---

If they are both behind a firewall, then it cant send the file without one of the clients doing some configuration.

---

Are you sure about that? I am able to (in most cases) send files to friends, even when both of us have firewalls - albeit very slowly. I came up with a theory that if neither can connect, then MSN just sends the file through the chat server somehow (packet header with a 'file transfer' flag or something).

If both clients have a firewall up, then they cannot connect to each other without one of them opening a port in the firewall. There is no way around that.

MSN messenger may have changed to allow people to send files through their server, but I could picture that killing their bandwidth.

Quote:

---

MSN messenger may have changed to allow people to send files through their server, but I could picture that killing their bandwidth.

---

I suppose so. But I did notice that after one certain upgrade to MSN, I was suddenly able to upload files to others.. and there's an "If you're experiencing slow transfer rates, click here to know why" popup, which proceeds to explain that you probably have a firewall. And it DOES give you a horrible transfer rate (about 1-2 kb/s).

by firewall configuration do you just mean that the firewall will ask the user if they want to allow an incomming connection from xx.xx.xx.xx?

Well, fancy new firewalls will ask the user if they want to allow an incomming connection, but many do not. For instance, my firewall (a linux box running iptables) requires me to manually open up ports that I want other computers to be able to connect to.

ok, this program is a bit like a chat program the server is constantly looping with a pause of 10 miliseconds to check for new data in one of the sockets. If i had to send the file through the server, would it be wise to make a new thread for that file transfer?
Because it would probably hog the other loop. Also, if the clients were able to direct connect would they have to use another port from the one they were using to connect to the server?

thanks so far :)

Quote:

---

If i had to send the file through the server, would it be wise to make a new thread for that file transfer?

---

Yes, it would be very wise.

Quote:

---

Also, if the clients were able to direct connect would they have to use another port from the one they were using to connect to the server?

---

Not only would you need to use another port, but you would need to create a new socket descriptor with a call to socket().

>>Not only would you need to use another port
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...

Quote:

---

Yes, it would be very wise.

---

I take it this new thread would have to use another port?

also, i tried to use getpeername() but it takes a sockaddr struct as the second parameter, how do i get the Ip address from this?
sa_data? or sa_family?

>>also, i tried to use getpeername() but it takes a sockaddr struct as the second parameter, how do i get the Ip address from this?
Look into inet_ntoa(), and use a SOCKADDR_IN instead of SOCKADDR, then pass (the sockaddr_in).S_addr.s_addr I think.

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.

Quote:

---

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:

Quote:

---

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 :)

Quote:

---

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().

>>because getpeername() will not accept a sockaddr_in struct, only sockaddr.
No, it takes a SOCKADDR*. Pass (SOCKADDR*)&theSockAddr_In.

Quote:

---

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 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 (without disconnecting in between). It will succeed.

The thing to remember here is that:
1) There is a central server, listening on port X
2) Each client connects to the central server on port X
3) Each client may also listen on port X, on their local machine.
4) Each client may connect to another listening client on port X

Each client acts as a server of its own, and requests/accepts connections on port X for peer file transfers, but that does not mean that it cannot also maintain a connection to the central server on port X.

Quote:

---

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 :)

Quote:

---

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

>>the client connects to the server (which is listening on port 22222) via port 10000.
>Hunter2 is talking about the destination port while bithub was referring to the source port.

Oh, great. So there's more than one kind? :rolleyes:

>>using the same port
So the distinction here is between "using" a port and "on" a port? Then does the term "port" in bithub's sense simply mean a socket of sorts?

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:

Quote:

---

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.

Ok, thanks. I get it now :)

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?

why dont you use the select statement.. its interrupt drive(imo)... its more efficient and does not waste cpu cycles...

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

>>And i just keep thinking is there anyway the clients could possibly send to much for the server to handle at once?
Isn't that the buffer overflow thing? Don't know much about it though.. Maybe the clients would just get errors (if non-blocking), or block, when they try to call send().

Quote:

---

Is there anyway the clients could possibly send to much for the server to handle at once?

---

Data will automatically be broken up into smaller chunks when you send them. The actual size of these packets will be based upon the senders MTU value, but it should be smaller than 1600 bytes for sure. If you are worried about losing data due to all the clients sending a bunch of information at once, and your socket buffer filling up, then I can put your mind to rest. If a packet gets lost somehow, a client will automatically resend the data. This is all worked into the TCP protocol, so you dont have to worry about programming any of it yourself. Now this is of course assuming you are using TCP packets, and not UDP. If you are using UDP, then there is a possibility of losing packets (especially under a high server load).

Quote:

---

or block, when they try to call send().

---

If TCP is the protocol being used, then they would block until the packet has been successfully sent. If necessary, the send method automatically resends the packet if it doesnt make it to it's destination. If the protocol is UDP, the function would return immediately, and you would never know for sure whether or not the packet got to its destination.

Quote:

---

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

---

I agree. A thread for each client would be a better idea.

>>then they would block until the packet has been successfully sent.
And if you want to prevent blocking, you can either use asynchronous winsock (it will return an error of WSAEWOULDBLOCK if you can't send right away), or use select() with the writefds parameter filled in.

Thanks everybody, this thread has been a great help to me.