Change to nmdc ADCGET in latest DC++ core?

[btx 0]

Two things in the latest DC++ core...

 

There seems to suddenly be some parameter tacked on to the end of ADCGET requests in the form DB# (where # is the number of bytes downloaded so far).  I'm not entirely clear of what the purpose of this new parameter is - I only noticed it because the client I wrote was complaining about it.  The only thing in the changelogs that sounded possibly related was some more accurate % completion feature... tho I don't see why this information would be passed to the uploading client (unless it's supposed to be returned somehow).  Is this parameter documented anywhere?  I tried to find a discussion on this new protocol extension, but couldn't find it anywhere.  WOnder if any other clients are as strict with their protocol msgs as mine is - it could cause compatibility issues?  Seems like this should be based on some Supports token, but looking at the code, it appears to always be appended to the adcget command.

 

For now, I'm just ignoring the token, but I'd feel more confident if someone could point me at some documentation of the feature

 

Apparently it's now checking the filelist for duplicate TTH entries.  It's kind of a bummer, because my bot has handlers for the filelist that arrange the share into different forms ... by date, by alphabetical order, by type, etc.  Anyway, the thing that seemed less than ideal wasn't that it doesn't accept duplicate files, but that the client displays an error msg rather than displaying the unique TTHs.  Probably is something that only affects me, so probably not a big deal.

 

Thanks in advance for any help or insight anyone can give,

btx

 

[Crise 26]

ADCGET is technically an ADC command, so it should be parsed with same rules as an ADC command even if used in the context of NMDC.

 

http://www.dcbase.org/forums/viewtopic.php?f=55&t=860

 

As for how ADC commands are expected to be treated by a client, generally named fields you do not recognize should be ignored... but as long as the command is otherwise valid the client (or bot) should not choke. It is easy to think of ADC commands as a map of keys and values, the first part of the commands arguments being positional and the second being by a named keys where each key is restricted to two characters. Duplicate keys are typically not a good a idea and thus not usually a thing.

 

Typically you won't run into any issues if you treat the named fields of an ADC commad as an equivalent of STL map, and the positional ones as an equivalent of an STL vector. Needless to say the guaranteed two character field names do permit some creative implementations of parsing and storing this. ADC as a protocol is designed to not choke when an addition like this is made, of course hubs and clients are responsible for exercising good judgement as to when a client is behaving maliciously, but typically if you can not parse something the protocol expects you to ignore it and let it bleed through in most cases.

 

Some real world implementations of hubs employ white listing when it comes to unknown commands sent to the hub (but the specification expects them to be dispatched according to their type), field names rarely get this treatment. Clients are expected to ignore unknown commands but not unknown fields within known commands.

 

http://adc.sourceforge.net/ADC.html#_general