-2

So private IP addresses are 192.168.00 ~ 192.168.255.255 or 10.0.0.0 or 172.16.0.0 ~ 172.31.255.255

If I accepted a client to my serversocket, I can get the client's remoteIp address by using socket.getremotesocketaddress(); But I suspect the IP address that I'm getting from this method is only the public IP address and it must have more than one client using same public IP as this one (one like you see when you go on to the website www.whatismyip.com). So if I want to make sure that my packet is delivered to the right person using some IP address or otherthing that uniquely identifies a person, what should I have to do?

Jason
  • 1,298
  • 1
  • 16
  • 27

4 Answers4

2

I don't think you can reliably recognize a returning user's machine this way. NAT will replace the "private" IP address with the public one your server is seeing. Alternative identifiers, like the MAC address also will be gone by the time the packet reaches your server.

Either build application level identification into your application (have the user or the client authenticate) or use a combination of not-so-unique contextual identifiers, e.g. through browser fingerprinting.

Community
  • 1
  • 1
martijno
  • 1,723
  • 1
  • 23
  • 53
1

How do you make sure your pakcet is delivered to right client using public ip address

The question doesn't make sense. If you accept a connection via TCP it is already connected to a unique client. All you have to do to talk to that client is to send bytes over that connection. There's nothing you have to do to ensure correct delivery at all.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I want to store unique identity of the client into database – Jason Sep 09 '12 at 07:23
  • And also, I want to know how P2P apps like torrent deals with this problem – Jason Sep 09 '12 at 07:24
  • 1
    @TemporaryNickName As the deliberate quotation makes clear, I am answering the question in your title. Neither your title nor your question says a word about databases. I suggest you clarify both your title and your question to express whatever it is that you actually are asking. We can only answer what you actually say. – user207421 Sep 09 '12 at 07:37
1

In my opinion, the only way would be to use HTTPS instead of HTTP. HTTP is a relatively weak protocol; with a reputation of beeing fairly easy to spoof and to spy on.

SylvainL
  • 3,926
  • 3
  • 20
  • 24
1

So if I want to make sure that my packet is delivered to the right person using some IP address or other thing that uniquely identifies a person, what should I have to do?

You can't ensure that. It is not technically possible.

What you can do is ensure that a packet cannot be read if it is delivered to the wrong person or machine. This can be implemented using various strong encryption schemes. And at the application level, HTTPS will ensure this provided that:

  • the client checks the certificates presented by the server thoroughly, and
  • the server's private keys are not leaked.

Under normal circumstances an HTTPS server does not have any way to definitively identify the client machine. You can address this using client certificates, but that requires a lot of effort to set up. This IBM note gives an overview:

So normal practice is to use plain HTTPS, combined with some application-level scheme to authenticate the users; e.g. user names and passwords, two factor authentication, biometrics, token generators and so on, etcetera.

But I suspect the IP address that I'm getting from this method is only the public IP address and it must have more than one client using same public IP as this one ...

Yea. This is increasingly common these days, given that the IPv4 space has been exhausted. For example a NAT gateway allows clients with "private" IP addresses to talk to an external service via a NAT gateway. To the external service, the connections appear to have the NAT gateway's IP address as the client address. There's nothing the service can do to find out what the "real" IP address is, and even if there was a way, it wouldn't uniquely identify the client.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216