Sorry, I wrote too fast. In fact, there is no problem at all since the map is for forward (client to worker) use only. Backward (worker to client) uses the backtrack.
So the only side effect of xoring the channel-IDs for the key would be non optimal load balancing. But it is completely negligible. So a 32 bit key is al-right.
Le 16/01/2014 09:38, Laurent Alebarde a écrit :
The footprint depends on the application but I agree with zerotacg it is generally acceptable. Anyway, it would be an option.The following won't solve the problem of huge applications with millions of clients and thousands of nanomsg hops, but I think that for most statefull applications, a good key could a xor of all channel-IDs from the client. At least, a client will never receive a message it should not, since the xor for the first hop is the client channel-ID itself.In case of key collision, when the first hop fails because the ID it would like to send to is not connected, it drops the message, the client reach a time-out. It should have available another route and retry on it.A better compromise to try to have near zero collision also on big applications could be a 64 bits key. Say we have 4 hops with IDs id1 to id4 and client is id0. Then the key would be:32 bits Low: id0 xor id2 xor id4 32 bits High: id1 xor id3 Le 16/01/2014 08:44, zerotacg a écrit :On 16.01.2014 07:29, Paul Colomiets wrote:Hi Martin, On Thu, Jan 16, 2014 at 8:00 AM, Martin Sustrik <sustrik@xxxxxxxxxx <mailto:sustrik@xxxxxxxxxx>> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/01/14 06:47, Paul Colomiets wrote: > From the text, it seems that only nearest peer id is checked > against, right? > > So if we have the following scheme: > > (many clients) -> A -> B -> (many workers) > > Only a single worker is used, because all clients of A look like > single client to B, right? Right. Sounds like using the whole stack as a key would scale better. Then, there are two more problems: 1. Memory consumption may be too high, as there at least are key per each client on each device. But in reality there is a key per "path" (i.e. many paths may be used in case of many-to-many connections)if you use the complete path as key (31 bit per hop) you can easily estimate the memory requirements: let's say 4 byte per hop, 1024 hops (in reality should be way less) and 10240 clients 4*1024*10240 = 41'943'040 bytes = 40 mb if you assume just 10 hops you could have 1'048'576 clients with the same memory foot print for the keys2. You need to expire keys, to free memory. Its not only a problem to choose default timeout, but also a potentially huge timeout queue Note: the point 1 also makes it easy to create DoS attack. -- Paul
