Requesting hub filtering of client traffic

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
Locked
Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Requesting hub filtering of client traffic

Post by Pretorian » 15 Aug 2012, 18:01

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.

Pirre
Junior Member
Posts: 31
Joined: 10 Nov 2009, 11:57

Re: Requesting hub filtering of client traffic

Post by Pirre » 16 Aug 2012, 15:39

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)

Locked