padding in cwdaemon packets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

padding in cwdaemon packets

Drew Arnett
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

Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: padding in cwdaemon packets

Thomas Beierlein-4
Hi Drew and Zoli,

Am Sun, 8 Dec 2019 17:51:12 +0100
schrieb Csahok Zoltan <[hidden email]>:

> 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

At that time it was unclear if cwdaemon needed a the send message as a
zero terminated string or not, so I added it to be sure.

Actual it seems that it is not needed. We can revert that commit.

73, de Tom


> 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  



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--