tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: padding in cwdaemon packets


From: Thomas Beierlein
Subject: Re: padding in cwdaemon packets
Date: Mon, 9 Dec 2019 07:27:49 +0100

Hi Drew and Zoli,

Am Sun, 8 Dec 2019 17:51:12 +0100
schrieb Csahok Zoltan <address@hidden>:

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]