Maximum allowed nick lengths

[RoLex 1]

Good morning.

 

I've never needed this until today, and I'm sorry for my language, but why the hell are nick fields limited to 35 and 28 characters?

 

Settings > General > Personal information > Nick < The field is limited to 35 characters.

Favorites > Hub > Properties > Identification > Nick > The field is limited to 28 characters.

 

Did anyone announce the official maximum allowed nick length for NMDC and ADC protocols? I didn't get that information. 

 

I'm running Windows 7 x86.

 

Regards.

[Mek 13]

Description is limited too. I was told that is beacuse of some old legacy NMDC clients. Probably same reason for nicks...

[Crise 26]

Original NMDC client limited description (and probably nick too) to 35 chars, then DC++ removed these limits (in a semi-recent, by their release cycle, version) and it opened up issues with certain hubsofts. With NMDC development mostly the way of the dodo, as long as NMDC protocol is in ApexDC some hard limit will exist. In order to avoid any future instance of sleeping issues emerging from hub software that are still used but no longer developed (Since it's proven that most hubowners still on NMDC are either unable or unwilling to do anything about the situation).

I'll check why the limits are inconsistent though, and will also try and find some documentation on it, but unfortunately most resources dealing comprehensively with NMDC are also hard to come by these days. From technical standpoint I do not believe it is not really the responsibility of the client to impose these limits, but as things are with NMDC, it is the responsible thing to do.

If you ask me, DC++ removed these limits out of spite more than anything else, and I understand it... I am all for their pro-ADC attitude, but factually we are not in a place yet where it can happen. When the end users and server hosts are mostly living in blissful ignorance.

[RoLex 1]

What kind of issue did it open up? Do you mean the HeXHub issue where following sutuation appears:

 

// client sends a nick that is more than 40 characters long (42 in this example)
$ValidateNick ABABABABABABABABABABABABABABABABABABABCCDD

// hub accepts client but cuts the nick to 40 characters
$Hello ABABABABABABABABABABABABABABABABABABABCC

// client compares its own nick with the nick resulted by hub
ABABABABABABABABABABABABABABABABABABABCC != ABABABABABABABABABABABABABABABABABABABCCDD

// nicks dont match so the client hangs there waiting for correct response until the hub times out and disconnects the client
...

 

If this is the case then I have already requested a HeXHub fix where hub disconnects the client and tells it that nick is too long. This is how all other hub softwares work, this is how NMDC works, either $Hello with same nick or $ValidateDenide.

 

I'm using these NMDC specifications: http://nmdc.sourceforge.net/NMDC.html

 

You could make nick fields limited to 255 characters, seems a reasonable buffer size to me.

[Crise 26]

The issue I am talking about was another one (and it was fixed, as far as I know), but the potential of theses issues appearing and not getting fixed, and more importantly hub owners and users not updating their software even if there is an update, then these issues become something worth to mitigate preemptively.

 

Like I implied above, I don't normally support defensive programming on client side (because it has the potential to hide issues, preventing them from being fixed). After all the server is ultimately responsible on how it handles unexpected behavior, (while the client is expected to behave in a responsible manner, it is  not something a server can rely on... if web servers did that the internet would not be what it is f.ex.). In this instance, however, considering the mentality of the user base (on both sides of the fence) and the general state of development for NMDC it seems warranted.

 

Regarding your suggestion it sounds reasonable and I will think about it.