Identify Users by Something Faster Than String

[pha3z]

I'm not sure how you are typically tracking connected users, but for myself (and I guess this is pretty common), an easy technique is to hash the IpPort string of user to form a dictionary key.

This might be an excessive micro-op (??) but some people might appreciate it:
If you're dealing with hi-thru-put of a LOT of messages, you could save some computation if hashing could be done on something better than a string. You could expose all IpPort combinations in a (16 byte, 2 byte) tuple or 18byte array to support IPv6:Port combinations. Hashing 18 bytes is going to be substantially faster than hashing a string representation.

I actually would prefer the byte-array version myself since it allows you to pass around an array pointer instead of the numeric ip values.

Thoughts?

[jchristn]

Hi @pha3z it's a great point. The primary reason I didn't do something like this is I wanted to opt for ease of use more than anything, and the string variant is pretty simple.

For personal projects, I generally don't rely on the ip:port for anything other than disconnection. I use the metadata as a means of exchanging session state (which also identifies the user, etc).

Cheers, Joel

(moving to discussion; if there's consensus on this, happy to add to the backlog, or if you/someone has a PR that is in line with the spirit of the library, I'd be open to a merge)

[pha3z]

What is the metadata you're referring to?

In "void MessageReceived(object sender, MessageReceivedEventArgs args)", I don't see any identifying information available except for args.IpPort.

[pha3z]

Oh. I think I figured it out. You're saying you put some cryptographically secure identifying data inside the message itself and use that to identify where the data came from instead of relying on the ip port. Since the ip port could be a spoofed packet, ip port is not a safe choice for identification to begin with. I should be using secured data in the message.

I feel very dumb for initially trying to use ip port as an identifier. :P

[pha3z]

On that note, I've worked with other network APIs that use various schemes to achieve that authentication like that. Do you have a personal favorite you recommend for sending in TCP messages with Watson?

[pha3z]

I just noticed Watson supports SSL. So I guess it would be secure enough to just send plain data with identifying information in the messages between client and server and trust the decrypted data on the recipient machine. No need for a internal signature on individual messages since the message is delivered on an established SSL pipe. Is that your recommendation?

[jchristn]

Hi @pha3z that's correct, I usually embed the material within the Dictionary<string, object> metadata parameter when sending (see https://github.com/jchristn/WatsonTcp/blob/23fd24293ef94a8b6989f7a91bb4ac9fc4cae543/WatsonTcp/WatsonTcpServer.cs#L373 for an example)

I haven't considered how other apps have managed authentication/trust and left that to the developer to figure out what works best. Between SSL/TLS, preshared keys, metadata attached to messages, in addition to whatever they want to embed in the message data itself, I felt there was ample surface area for supporting whatever is best for the use case.

Re: SSL and sending plaintext data in the message and relying on SSL to obfuscate it, I would say it's fine as long as your keys are secure and there's either explicit trust (keys installed locally) or a trusted authority in the environment. Cheers, Joel

[pha3z]

Back on the string ip port issue, so everything in Watson resolves around string -- even Server.Send(). I presume Watson must translate the string to an underlying open socket. So there's a cost in that direction also, isn't there?

[jchristn]

That's correct, internally there is a Dictionary<string, ClientMetadata>:
https://github.com/jchristn/WatsonTcp/blob/23fd24293ef94a8b6989f7a91bb4ac9fc4cae543/WatsonTcp/WatsonTcpServer.cs#L146

And it's a ConcurrentDictionary which I would assume also adds some overhead/cost beyond the string hashing.

[pha3z]

Since we're even discussing this, I'm going add another point for the sake of posterity:

A HashSet completely eliminates key storage. If the string is available as a reference in ClientMetaData (which I'm guessing its not), you can use a custom IEqualityComparer to use HashSet instead of dictionary and still key on the ipPort.

Also, for what its worth, the default HashSet in .net is a pitiful animal. They really botched it. I easily modified the .NET HashSet to support AddOrReplace() so that you can do extremely rapid additions to the hashset. It outperforms a dictionary due to the fact that you don't store key information.

If the idea of optimizing the address handler to use byte[] address hashing actually takes off, its worth considering going a step further and completely replacing the ConcurrentDictionary with a custom ConcurrentHashSet.

I have a feeling nobody is actually interested in this. But I thought its worth noting.

Also I really wish .NET BCL would incorporate a ConcurrentHashSet and make the default HashSet Non-Sucking.

[pha3z]

It just occurred to me: do we even need the dictionary lookup to send data to a client? Would it be possible to expose a function delegate or some other type that would allow sending data to a client without doing a hash lookup at all?

[jchristn]

Hi @pha3z i.e. on connect, provide the delegate in the ConnectionEventArgs perhaps? https://github.com/jchristn/WatsonTcp/blob/master/WatsonTcp/ConnectionEventArgs.cs

[pha3z]

Yeah thats a good idea. It can be Action<byte[], length, [offset = 0]> which could invoke an underthehood closure that captures the socket. This 100% eliminates lookups and gives nearly direct to socket performance.

User would invoke the delegate instead of calling server.send().

This use of closures is actually a pattern I follow in a lot of code I write these days. It's extremely high performance while remaining very flexible.

On different note: for identification, I moved to generating a UUID v4 session token on the server and handing that to the client. Client identifies itself as sender of future messagss by including the token.. This allows clients to reconnect(even on a different port) and resume their session seamlessly. That was thanks to you pointing out that I shouldn't be relying on a stable address for identification. :)

I think one of us should create a write-up explaining that client identification has to use a shared data mechanism and that relying on ipport is fundamentally flawed as a primary means. A lot of people new to custom server code won't be aware of this. Many people aren't even familiar with NAT and that clients will probably be on floating endpoints.

[pha3z]

Fwiw, I did not end up using the Metadata feature of Watson. It felt easier to just include the session token in my serialized wire message.

[jchristn]

Hi @pha3z sorry it took so long to get back to you; we moved and had other (positive) life activities.

I'm open to the idea of changing the identifier for a connection, perhaps even allowing the user to have some methods to add their own metadata to a given connection (and then methods to find connections by that metadata).

My big fear is that it will be a really big disruption to the current experience. Do you have suggestions on how to mitigate that, or, would you be interested in putting together a PR (or series therein) around it?