Page 1 of 1

Requesting hub filtering of client traffic

Posted: 15 Aug 2012, 18:01
by Pretorian
The recent user commands and CDM issue; hubs forward a B-type CMD message. In a hub that doesn't know about UCMD, it rightly forwards the messages. In a hub that does know about UCMD, but doesn't filter, are more troublesome. But it doesn't actually boil down to a hub problem, since, again, the clients might just have something new going on. (And I can admit that it may have been a premature assumption in saying that there's a massive security hole, especially for the hubs).

I thought about the potential commands that are of this nature and I could only really think of UCMD, but this is a general problem; clients send stuff that the hub forwards to others, potentially using memory or CPU on the receiver. Also, while there is a (tehnical) way for the client to decide "hm, that's a B-type CMD, I should just ignore that since that came from a user", the client _should not_ all according to the rule about where the information is parsed; the type shall only be used for message parsing.

If we apply a different solution though; we ask the hub to filter stuff we want or don't want. Think of this; you say to the hub "I am not interested in B-type CMD", so the hub doesn't forward it to you. The hub will possibly eat some memory, but might actually be able to save on bandwidth since some (all?) clients might not want a particular type of message. Say, you would "naturally" not send searches or CTMs to a client that doesn't share anything. There's multiple ways we could implement this and I haven't thought it through yet.

In fact, not only could we restrict things to types, we could restrict things to commands or even parameters. ("I don't care about the PM flag" or "I don't want MSGs", but not using AW2 in INF.)

I haven't thought this through much, but I thought a discussion would be in order.

Re: Requesting hub filtering of client traffic

Posted: 16 Aug 2012, 15:39
by Pirre
Wel let's call this solution a "Dynamic Routing table" for ADC CMD's and it sounds very promising.

I would exclude all BASE commands from this system so these can be threaded same way as now and limited on types. (including base commands would take more resources running trough a table of individuale SID's to see where to send then the band saved and would force the client to send them on login).

For the all CMD's outside BASE a user should on login (probebly best in IDENTIFY) send the hub a list of CMD/TYPE,TYPE, ..;
This way a hub could build a table with CMD/TYPE SID,SID,SID and on receipt of a not BASE CMD use this for routing.

Think the above would even save on resources ... instead increasing.

In time this could even replace the IF client Support extention then send ... when a hub would add those SID CMD itself to that routing table if not received (for compability reasons and have only 1 routing system)