unless you don't mean a specific received packet from a listening socket in ur software, then i think you need a sniffer-like software. check this software on code project: http://www.codeproject.com/KB/IP/CSNetworkSniffer.aspx
understand that this address may not be what you expect... passing through routers and proxies will give you the ip addresses of the router or proxy server, not the actual client's ip address.
using( Socket server = new Socket( AddressFamily.Internetwork, SocketType.Stream, ProtocolType.Tcp ) { server.Bind(new IPEndPoint( IPAddress.Any, 7777 ) ); server.Listen( 10 ); // loop while the server is running while ( serverIsRunning ) { using ( Socket client = server.Accept( ) ) { Console.WriteLine( "Client address: {0}", ((IpEndPoint)client.RemoteEndPoint) ); // do whatever you do w/ the client socket } } }
Actually, I have a Client/Server system running (has been for a few years now) which uses the Socket.RemoteEndPoint Property to determine the identity of the client. It returns the client's public IP-address every time. Is this a coincidence?
how have you verified that it's the clients actual public ip? ip's are ip's and a proxy or router will appear the same as an actual ip. if you do get their actual ip then you dont have an any clients using proxies or complex networks.
I verify the IP by the fact that the app works xD so I'm lucky that way. If one of my clients were to use a proxy or something else that breaks this validation, are there any options other than to send and identifier with the packet itself in order to identify the client?
unless your app opens a server socket, and your server initiates a new connection back to the client then it doesn't matter. the client initiating a connection to your server is all you need. the only time you would run into problems is if you used just the ip address, where you had two individuals connecting to the server through the same network or proxy. but if you use the entire ip endpoint this is fine because each client will use a different port. you won't notice a problem any time the client opens the connection because the router / proxy will maintain the session and redirect traffic correctly, but the server back to the client scenario, the proxy / router will not know where to route that traffic. The only other way you could identify clients w/ out ip/port would be for the client to create, maintain and send a guid. I know of other systems who use either ip or ip/port for client identification, and ones that use just the IP have ended up needing to be rewritten because of the problem discussed. I've also written large scale servers that used ip/port for client session across the server mesh and have never had a problem with it, even with proxies.
2 answers
unless you don't mean a specific received packet from a listening socket in ur software, then i think you need a sniffer-like software. check this software on code project: http://www.codeproject.com/KB/IP/CSNetworkSniffer.aspx
answered one year ago by:
1556
You can't get it from the packet payload. Rather you get it from the incoming client connection itself.
Socket.RemoteEndPoint. Cast this to an IPEndPoint and get the ip/port of the client.
understand that this address may not be what you expect... passing through routers and proxies will give you the ip addresses of the router or proxy server, not the actual client's ip address.
answered one year ago by:
2309
2499
Actually, I have a Client/Server system running (has been for a few years now) which uses the Socket.RemoteEndPoint Property to determine the identity of the client. It returns the client's public IP-address every time. Is this a coincidence?
2309
how have you verified that it's the clients actual public ip? ip's are ip's and a proxy or router will appear the same as an actual ip. if you do get their actual ip then you dont have an any clients using proxies or complex networks.
2499
I verify the IP by the fact that the app works xD so I'm lucky that way. If one of my clients were to use a proxy or something else that breaks this validation, are there any options other than to send and identifier with the packet itself in order to identify the client?
2309
unless your app opens a server socket, and your server initiates a new connection back to the client then it doesn't matter. the client initiating a connection to your server is all you need. the only time you would run into problems is if you used just the ip address, where you had two individuals connecting to the server through the same network or proxy. but if you use the entire ip endpoint this is fine because each client will use a different port. you won't notice a problem any time the client opens the connection because the router / proxy will maintain the session and redirect traffic correctly, but the server back to the client scenario, the proxy / router will not know where to route that traffic. The only other way you could identify clients w/ out ip/port would be for the client to create, maintain and send a guid. I know of other systems who use either ip or ip/port for client identification, and ones that use just the IP have ended up needing to be rewritten because of the problem discussed. I've also written large scale servers that used ip/port for client session across the server mesh and have never had a problem with it, even with proxies.