[2013-01-27 21:06:21] UDP search results are sent prefixed with a CID. couldn’t they just be sent with an SID, like other messages, since the hub can be found from the token?
[2013-01-27 21:09:56] poy: Only thing I can think of is that there might be two (different) users that send the same token and happen to have the same SID.
[2013-01-27 21:12:19] poy: You should also be able to properly send a result even if the client (for some reason) isn’t connected anymore.
[2013-01-27 21:13:10] 2 clients on the same hub can’t have the same SID?
[2013-01-27 21:14:04] Two different hubs.
[2013-01-27 21:16:12] It’s unlikely that there are two users at the same time with the same SIDs, but entirely possible. (Depend obviously on hub generation of SIDs.)
[2013-01-27 21:16:42] If clients send different tokens for each hub, then obviously that wouldn’t be a problem anymore.
[2013-01-27 21:17:42] Pretorian: that’s what i meant. in the context of a client using different tokens per hub, there is no SID conflict.
[2013-01-27 21:18:12] poy: The spec doesn’t mandate that implementations generate new tokens, though.
[2013-01-27 21:19:01] It also doesn’t do anything in the case if the client disconnects from the hub.
[2013-01-27 21:22:05] Also; you and I are on the same two hubs. You search. With what SID should I respond?
[2013-01-27 21:22:38] (I could respond with both in terms of sending a total of 20 results, but that’s pointless.)
[2013-01-27 21:23:16] with the SID of the hub that received my search request. but i agree with the other 2 points. too bad, could have saved a few bytes. >
[2013-01-27 21:23:31] (These are simply what I can think of on the top of my head. I don’t remember the reasons, to be honest.)
[2013-01-27 21:24:29] You do a BSCH in both hubs, so I receive two searches for the same user… No need to respond with redundant information.
[2013-01-27 21:25:15] This is assuming that the CID is re-used on multiple hubs and not regenerated per hub basis…
[2013-01-27 21:27:05] By the way, tokens aren’t always available for U-type messages…
[2013-01-27 21:27:31] (STA.)
[2013-01-27 21:31:40] ah, good point on the 2 hubs situation. i’m guessing the search will be processed twice as it stands, so there will indeed be 20 results… well i’m off, have a good evening. >
Also because a client sending an U message may not necessarily be in a hub and thus have a SID, that could be the case for example when using DHT or a similar system.