CODEWITHSUNDEEP
c#asp.net.net
maxiperez
maxiperez

Reputation: 1480

How to identify each remote computer with a unique ID

How do I identify a remote computer with a unique ID.

IP address may not be unique enough on networks which share IP. MAC or other hardware information are not available or depend on OS, Architecture, configuration, etc.

Cookies are a possible solution. I could delete the cookies on my browser, to change the browser. Also I must read a lot of information (each client on each stored cookie). In my database does not exist any relation.

Which could be the solution?

Upvotes: 2

Views: 1869

Answers (2)

Levon Ravel
Levon Ravel

Reputation: 100

Another way to skin the cat is to use the IPEndPoint, first send a request to a given connection. From here you will be handed back a return packet, you can use IPEndPoint.GetHashCode().Use that integer as your ID what is nice about it is its 4 bytes and not a complete string hash.

private void ReceiveUdp()
{
    while (IsRunning)
    {
        var packet = RavelNet.CreatePacket();
        _count = RnetSocket.ReceiveFrom(packet.Data.Array, ref packet.RemoteEp);
        //I am storing the endpoint in my packet but you can do YourIPEndPoint.GetHashCode(); will return an integer identifier
        packet.Data.Ptr = _count;
        packet.ReadHeader();

        lock (_inProcess)
            _inProcess.Enqueue(packet);
    }
}

Upvotes: 0

Nicholas Carey
Nicholas Carey

Reputation: 74227

If you want a permanent identifier, the short answer is that you don't have one. The MAC address isn't available to you. It's available to the router, but by the time it gets to you, it's been stripped off (actually, each router between you and the client machine replaces the MAC address with its own).

You've got IP address (and if it's coming from a private, non-routable subnet or if the request is being proxied), all you've got is the single IP address representing the client subnet.

You can get the session id, though:

HttpContext.Current.Session.SessionID

The problem with that is that it's a fairly transient value. You could alternatively set a persistent cookie with an expiration date far in the future.

The client system, of course, is free to toss the cookie (or not to accept it).

Upvotes: 4

Related Questions