CIDM - Client Implementation Debug Mode

[Pretorian]

While digging through old logs and code, I found an extension that had been dubbed CIDM. I've slightly modified the text since it's original incarnation.

CIDM - Client Implementation Debug Mode

If a client signals support for CIDM to the hub, the hub should treat the client in a special debug mode, and not kick the client; even if it's violating something that may warrant a kick.

Flag CIDM in SUP and in the INF's SU field.

[andyhhp]

This is just open for abuse. What happens if a client wants to make trouble and send CIDM as a guarentee that it wont get kicked?

My view would be that this would be better as a PID whitelist in the hub, rather than a client saying "honest gov. im not here to intentionally cause problems"

~Andrew

[darkKlor]

I think the barrier to entry with ADC is low enough that you can avoid getting yourself kicked after a short amount of time. If you do get kicked, you're probably doing something wrong and will be greatful for the debugging message that getting kicked gives you.

[Toast]

imho reject this extension since the abuse risk is too high

[Pretorian]

Dug up quotes;

[2007-11-04 17:12:46] <Pretorian> arne: Perhaps add another STA code? "Search performed too soon. Flag "TL" is an integer specifying the number of seconds left until it's allowed again"
- [2007-11-04 17:14:39] <FarCry> if at all then a more general "Server Busy" with a retry timeout
[2011-01-02 22:57:05] <Pretorian> Some additional interesting things;
[2011-01-02 22:57:07] <Pretorian>
- [2007-11-04 17:12:46] <Pretorian> arne: Perhaps add another STA code? "Search performed too soon. Flag "TL" is an integer specifying the number of seconds left until it's allowed again"
- [2007-11-04 17:14:21] <pur> atleast i can do somethiing else while downloading the lastest from arne
- [2007-11-04 17:14:39] <FarCry> if at all then a more general "Server Busy" with a retry timeout
- [2007-11-04 17:15:54] <fusbar> as with email?
- [2007-11-04 17:16:53] <fusbar> smtp
- [2007-11-04 17:16:59] <fusbar> hasen't it got something similar
- [2007-11-04 17:17:11] <Pretorian> Though, then flag also the FOURCC.
- [2007-11-04 17:18:06] <FarCry> I'm not sure the protocol should support "be nice, I'm broken" messages at all
- [2007-11-04 17:20:16] <PseudonympH> but they're going to be needed anyway; i don't see search timeouts going away
- [2007-11-04 17:21:05] <fusbar> farcry: yes, the question is if it gets more complicated than it gives.
- [2007-11-04 17:21:05] <PseudonympH> so we might as well make a clean way to do it instead of it just sending an IMSG
- [2007-11-04 17:21:13] <fusbar> i.e., complexity with no use whatsoever
- [2007-11-04 17:21:15] <FarCry> you can add flags to generic STA codes and let clients and hubs handle them on a different level
- [2007-11-04 17:21:42] <FarCry> that's the idea behind extensibility
- [2007-11-04 17:22:02] <FarCry> (if that's a word )
- [2007-11-04 17:24:02] <pur> might want to standardize the STA a bit though
- [2007-11-04 17:24:16] <pur> but thats somewhat done already
- [2007-11-04 17:24:43] <arnetheduck> http has a server busy code
- [2007-11-04 17:25:08] <FarCry> you could have a general retry timeout after which sending the same message that caused an error might make sense again
- [2007-11-04 17:25:12] <fusbar> would dc++ care about a to busy code? )
- [2007-11-04 17:25:46] <arnetheduck> in a distant future =)
- [2007-11-04 17:25:53] <PseudonympH> well, people might complain that they're searching and nothing is happening if it ignores it
- [2007-11-04 17:26:15] <FarCry> for a search, the client gets the echo anyway and if it doesn't, it'll know the search was not relayed
- [2007-11-04 17:26:26] <PseudonympH> you have a point
- [2007-11-04 17:26:40] <fusbar> farcry: yes, but it doesnt know the PING-time
- [2007-11-04 17:26:44] <fusbar> one coule argue against that
- [2007-11-04 17:26:53] <FarCry> a client can provide visual feedback for that echo
- [2007-11-04 17:28:07] <fusbar> btw, a none-trivial thing not stated in the protocol
- [2007-11-04 17:28:12] <fusbar> which one might want to say
- [2007-11-04 17:28:24] <fusbar> is that messages should be handled in order
- [2007-11-04 17:29:03] <fusbar> the hub shouldn't (or should if you think that) be allowed to rearrange messages in the order they have arrived
- [2007-11-04 17:29:59] <FarCry> would that be a general rule or one specific to certain command types?
- [2007-11-04 17:30:12] <FarCry> I know it's important for MSG
- [2007-11-04 17:30:36] <fusbar> not sure on which level, but i guess it should be mentioned somewhere
- [2007-11-04 17:30:44] <pur> if the source is the same, they always arrive in the same order they are sended
- [2007-11-04 17:31:00] <fusbar> people will probably want to B-casts to have smaller amounts of packets
- [2007-11-04 17:31:01] <PseudonympH> a passive search won't get the echo, though
- [2007-11-04 17:31:07] <PseudonympH> since it will only be sent to active users
- [2007-11-04 17:31:23] <fusbar> pur: yes, but a hub can rearrange them
- [2007-11-04 17:31:29] <fusbar> priotorize for example
- [2007-11-04 17:31:35] <fusbar> MSG before SCH et.c.
- [2007-11-04 17:31:50] <fusbar> or vise versa
- [2007-11-04 17:32:19] <pur> ye but, the one sending is in control of that,
- [2007-11-04 17:32:33] <pur> since tcp.ip handles the ordering for you
- [2007-11-04 17:32:43] <FarCry> no, not necessarily
- [2007-11-04 17:32:58] <pur> and if the client wants it different, there's nothing you can do about it
- [2007-11-04 17:33:07] <FarCry> the protocol doesn't say that the receive order should be kept for forwarding
- [2007-11-04 17:33:11] <pur> it can just aswel ignore any higher protocol agreements
- [2007-11-04 17:33:34] <fusbar> pur: you are looking at this at the wrong level
- [2007-11-04 17:33:38] <fusbar> see farcry
- [2007-11-04 17:34:30] <FarCry> I think it's only important for MSG and perhaps QUI should mention it also
- [2007-11-04 17:34:48] <FarCry> otherwise there's nothing in BASE which requires any kind of order
- [2007-11-04 17:35:03] <fusbar> exactly
- [2007-11-04 17:35:33] <fusbar> handshake is ordered ofcourse
- [2007-11-04 17:35:37] <fusbar> by definiton
- [2007-11-04 17:35:40] <fusbar> but after that
- [2007-11-04 17:36:01] <FarCry> handshake is point to point - the transport layer handles the order
- [2007-11-04 17:37:14] <pur> the handshake gets it order kinda by the messages that may be sended in every state
- [2007-11-04 17:37:36] <fusbar> yes, but back to the point
- [2007-11-04 17:37:46] <fusbar> maybe its over-defining things
- [2007-11-04 17:37:59] <fusbar> and setting to much up in stone to define an order
- [2007-11-04 17:38:09] <fusbar> most probably will try to maintain it
- [2007-11-04 17:38:37] <pur> it think it's to much
- [2007-11-04 17:39:17] <pur> or rather
- [2007-11-04 17:39:26] <pur> hcum ot s'ti kniht ti
- [2007-11-04 17:39:28] <pur> =)
- [2007-11-04 17:40:08] <FarCry> if you consider the specification as something by which you can verify an implementation, something should be mentioned in MSG
- [2007-11-04 17:41:53] <fusbar> pur: i think you still have not understood what we discuss. )
- [2007-11-04 17:43:35] <FarCry> is right
- [2007-11-04 17:43:38] <FarCry> is wrong
- [2007-11-04 17:43:43] <FarCry> fusbar
- [2007-11-04 17:43:44] <FarCry> pur
- [2007-11-04 17:43:51] <FarCry>
- [2007-11-04 17:45:16] <FarCry> well, there's also "it doesn't show up in searches"
- [2007-11-04 17:46:18] <pur> i understood fusbar, i just overdid it one step more
- [2007-11-04 17:47:01] <pur> you can't order messages coming from more than 1 source anyway
- [2007-11-04 17:47:12] <pur> and it's silly to do it, if it comes from 1 source
- [2007-11-04 17:47:30] <FarCry> you can
- [2007-11-04 17:47:44] <FarCry> but I don't think we want to
- [2007-11-04 17:49:12] <FarCry> you can postulate accurate timers, define a synchronization point and add timestamps to messages
- [2007-11-04 17:49:47] <FarCry> I guess you'd need "tick messages" too
- [2007-11-04 17:50:01] <pur> how would you handle a very delayed message?
- [2007-11-04 17:50:35] <pur> a delay of 1 second would mess it up already
- [2007-11-04 17:50:51] <pur> unless you want to see new messages arrive every 5 minutes
- [2007-11-04 17:51:09] <FarCry> not if you have a timeout of 5 minutes and implement that as a natural delay
- [2007-11-04 17:51:12] <PseudonympH> turn chat into a mailing list
- [2007-11-04 17:51:51] <FarCry> there's nothing that prohibits insertion into the chat display, either
- [2007-11-04 17:51:59] <pur> haha,
- [2007-11-04 17:52:03] <FarCry> I already said we don't want that
- [2007-11-04 17:53:27] <pur> maby we should ask cerf into the hub, he resigned last week anyways
- [2007-11-04 17:53:43] <FarCry> should there be a recommendation for implementations to process messages as fast as possible?
- [2007-11-04 17:55:12] <FarCry> seeing that $MyINFO delays already cause some confusion

- [2007-01-21 17:04:46] <FarCry> btw: I hereby declare the SUP fourcc "CIDM" occupied
- [2007-01-21 17:05:40] <FarCry> should probably add that to the Wiki instead
- [2007-01-21 17:07:31] <Pretorian> What is it?
- [2007-01-21 17:08:49] <FarCry> my hub won't disconnect on any problems when the client includes this in the support set and will try to strictly parse every message and send verbose ISTAs
- [2007-01-21 17:09:00] <FarCry> "Client Implementation Debug Mode"
- [2007-01-21 17:11:13] <Pretorian> Sounds "dangerous".
- [2007-01-21 17:11:52] <FarCry> well, you can let only privileged users use it
- [2007-01-21 17:12:18] <FarCry> looks like I'm too noobish to add an extension to the wiki
- [2007-01-21 17:13:16] <Pretorian> Why not instead have a ticket system? "if user does something that warrents a kick, increase the ticket by one. if ticket is x, kick".
- [2007-01-21 17:14:13] <FarCry> I do that for ordinary connections
- [2007-01-21 17:15:58] <FarCry> it's mainly to allow testing clients even when not everything is working correctly
- [2007-01-21 17:16:10] <FarCry> and to get some more feedback
- [2007-01-21 17:16:11] <Pretorian> If only privileged users should use CIDM, the ticket system could instead have an infinite amount of tickets for those users.
- [2007-01-21 17:16:33] <FarCry> yes, but that doesn't handle the strict parsing and verbose ISTAs
- [2007-01-21 17:16:54] <Pretorian> Crash and burn is probably better than "oh, this was seriously fucked up but I'll let you be here anyway".
- [2007-01-21 17:17:33] <FarCry> I don't know, it virtually comes for free and so I decided to implement it
- [2007-01-21 17:18:04] <Pretorian> Hm... I guess I'll add it to Elise, then.
- [2007-01-21 17:18:05] <FarCry> it works both ways, of course - I can use it to check if the hub's parser works correctly too

- [2007-01-21 18:45:49] <Pret> Though, for once I agree; It sounds too close to CID. Like CID Management or something.
- [2007-01-21 18:47:07] <fusbar> Aren't you after some "verbose" and "strict" mode?
- [2007-01-21 18:47:17] <fusbar> can't you borrow something from all those gcc flags?
- [2007-01-21 18:50:33] <FarCry> CDBG?
- [2007-01-21 20:03:27] <Pret> Why add a new field? Can't you just do STA 100 <msg>?
- [2007-01-21 20:04:40] <FarCry> Client Debug, that's all
- [2007-01-21 20:05:08] <FarCry> perhaps DBGM for DeBuG Mode would be better, so it can be used independently
- [2007-01-21 20:05:42] <FarCry> and the message can become rather long if I include the original message, so I'd rather have it in a separate parameter
- [2007-01-21 20:08:01] <Pret> For possible future parameters, or what?
- [2007-01-21 20:08:56] <FarCry> no
- [2007-01-21 20:10:11] <FarCry> why is there FL, FC and IP when you can simply include that in the message?

What I said when I posted this in DCDev Public;

[2011-01-03 17:36:24] <Pretorian> "give me verbose error messages", essentially.
[2011-01-03 18:22:12] <Pretorian> Any other reference is that I re-stating above, basically, and that there should be an implementation in Aegaeon.
[2011-01-03 18:22:37] <Pretorian> (I have no idea where you can find a copy of Aegaeon nowadays, though. It used to be on BerliOS.)