What would you change if you could?

What would you change with ADC if you could, assuming you didn’t need to care about current implementations och what is or isn’t in the current spec?

Would you add a new feature? Remove one? Move an extension to the base spec?

What I’d (potentially) change (in no particular order);
•Add feature versioning
•separate app name from version
•add ‘TS’ in MSG to BASE
•add hash set (for directories etc)
•add SEGA to BASE (withholding the FCC of course)
•specify that ‘adc’ is an acronym for ‘advanced direct connect’
•possibly separate chat functionality from file sharing in BASE
•‘hidden’ in the CT field in BASE
•possibly adding NAT-T to BASE
•add referrer in BASE for C-C
•allow other fields in SUP
•mandate that fields that signal FCCs shall use one convention for separator and that multiple FCCs are valid
•possibly clarify padding, endian etc for Base32, network order etc
•possibly clarify the message syntax for some types of parsers
•add invalid feature to STA
•allow for more error codes (break up severity and error code)
•add failover hubaddresses to BASE
•add free slots to BASE
•add locale field to BASE
•require that all clients send I4/I6
•possibly specify a common convention for hash field names
•possibly add an additional CT enumeration value for chat group

  • Add feature versioning
  • add hash set (for directories etc)
  • specify that ‘adc’ is an acronym for ‘advanced direct connect’
  • ‘hidden’ in the CT field in BASE
  • possibly adding NAT-T to BASE
  • add referrer in BASE for C-C
  • add invalid feature to STA
  • allow for more error codes (break up severity and error code)
  • require that all clients send I4/I6

basically, different versioning…
referrer is a good thing, but it doesn’t work very well (see case when one phisical hub has couple of addresses and has port forwarding - not a good hint… i’d suggest some kind of hub hash, when hub is recognized by hash, not an address)

Well I still would like a better MAC digest for UDP messages, other than that I have no major complaints on the protocol.

Are you planning on making a rewrite or something?

Not really. It’s just useful to know what people would do if they wouldn’t be constrained with compatibility (e.g. by removing a bunch of stuff for simplicity etc).

Is it beyond the bounds of possibility to have ADC/2.0 non backward compatible?

There are a few issues with the protocol at the moment which make it difficult to use in places, specifically with respect to versioning, ambiguities in the grammar and password negociation.

It seems to me that a fairly compatible version 2 could be made which lifts these restrictions with minimal overhead to the programmers, but leaves behind the baggage holding it back.

Just a thought,


Happy new year and marry chrimiss