UDP Chat Server Stops Recognising Commands

[Okame42]

I was having a QSO via cq.morserino.info and apparently I was disconnected half way through my over. It was mentioned by the other party that I suddenly stopped transmitting even though I was still keying.

I thought I'd try running the chat server on my own computer to see if the problem was local to me. I noticed that after a certain period of time the chat server would stop recognising HI and :BYE.

I've tracked the problem down to the 'mopp' function. Every time this function is called, the serial number is incremented by one. As soon as the serial number hits 64, the 'mopp' function no longer returns the correct encoded version of the text passed to it. This means that, no matter how many times you send HI or :BYE, the server won't recognise them. It also means that, if the client times out, the server sends a garbled mess at a random speed instead of :BYE at 30wpm.

I appeared to fix the problem by resetting the serial number to 1 whenever it reached 64 but I'm not sure whether this is sensible because I don't understand how the serial numbers are used by the morserino. Regardless. I'm not sure whether any of the above accounts for the disconnect that happened to me on cq.morserino.info. I guess it might've just been my WiFi dropping.

[oe1wkl]

Please can you be a bit more specific? In which source file is the mopp function, which line number?
Thanks, Willi

[Okame42]

Sorry about the lack of detail. There's only one file that actually contains any code so I thought you might know what I meant.

The 'mopp' function is on line 43 of m32_chat_server.py

[oe1wkl]

Oh, I see…. You sent the error report to the wrong person / wrong project. The chat server has been programmed by Wojtek, SP9WPN, and is not part of the Morserino-32 source…. The serial number in MOPP is a 6 bit number, starting with a random value, and flows over from 63 to 0. It is currently not really being used in the Morserino; the idea was to be able to determine lost packets (i.e. lost words). So it can actually be ignored when receiving packets. I am not sure what the chat server is doing with the serial number? 73 Willi OE1WKL

…

Am 28.02.2022 um 22:15 schrieb Okame42 ***@***.***>: Sorry about the lack of detail. There's only one file that actually contains any code so I thought you might know what I meant. The 'mopp' function is on line 43 of m32_chat_server.py <https://github.com/sp9wpn/m32_chat_server/blob/726f5880713c0f7e6c9546982c4c8e318b3bb268/m32_chat_server.py#L43> — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZR72AOMAJUBWTNGH7ICGTU5PQWHANCNFSM5NV3IV5A>. You are receiving this because you commented.

[oe1wkl]

On 2022-02-28 23:00, willi.kraml wrote: Oh, I see…. You sent the error report to the wrong person / wrong project. The chat server has been programmed by Wojtek, SP9WPN, and is not part of the Morserino-32 source…. The serial number in MOPP is a 6 bit number, starting with a random value, and flows over from 63 to 0. It is currently not really being used in the Morserino; the idea was to be able to determine lost packets (i.e. lost words). So it can actually be ignored when receiving packets. I am not sure what the chat server is doing with the serial number?

Hi Willi, My original chat server just renumbers serials in sent messages, starting from 1. Received serial numbers are ignored. Wojtek

…

-- 73! Wojtek SP9WPN

[Okame42]

You sent the error report to the wrong person / wrong project

I wondered whether you were the right person to contact but I didn't have a choice. There's no way to log an issue on Wojtek's Github and I thought perhaps this was the place because there is another issue open here about the UDP chat server.

flows over from 63 to 0

It didn't seem to be flowing over to zero on the chat server until I added my fix but I think that answers my question. Thanks for your help and contacting Wojtek on my behalf.