Re: padding in cwdaemon packets

[Csahok Zoltan]

Hi Drew,

Trailing zero and newline have most likely historical origin.

The zero was introduced abt 9 years ago in this commit:
https://github.com/Tlf/tlf/commit/5a2be34d01b296bc8b8d8b362407cc3077e3c6d8#diff-8be0c8c50997da170641d3392ba81b5a
Apparently cwdaemon needed it. Now it does not for sure, neither any newline.
It actually removes NL:
https://github.com/acerion/cwdaemon/blob/master/src/cwdaemon.c
(line 1140)

winkeydaemon as a defensive measure silently ignores non-processable characters.
Probably cwdaemon (libcw) does the same.

Technically the trailing NL is a result of not chopping it after fgets().
While for CW it is irrelevant, it might make sense for digital modes.
Not sure, though, as digital keyer code could add NL on its own.

So all in all I think we could get rid of both trailing chars without issues.

73,
Zoli


On Sat, Dec 07, 2019 at 04:35:28PM +0000, Drew Arnett wrote:
> Doing some debugging and cleanup of my pywinkerdaemon implementation
> of cwdaemon.  (I introduced some bugs with recent feature
> introduction.)
> 
> A few years ago, I looked at the UDP packets several different
> cwdaemon clients sent.  Some, like TLF, send a single trailing null
> character which is not needed.  Some sent quite a lot.  (Allocated a
> max UDP data structure, wrote nulls, then wrote the message to the
> beginning.  Still, should have not bothered transmitting all that
> padding.)
> 
> Looking at tlf as included in debian 10.2 today, I see it also has a
> \n (0x0a) character between the end of the CW message and the single
> null character.
> 
> I recommend that tlf doesn't transmit either the 0x0a or the 0x00
> trailing characters.  Unless this would break other independent
> cwdaemon implementations.  Anybody know?
> 
> Best regards,
> 
> Drew
> n7da