Known Relay bugs
All of these Lacewing Relay bugs below have been addressed in Lacewing Blue set.
Lacewing Relay Client, Relay Server and Webserver:
- An attempt to add a short/byte value to binary message to send that is too large for to fit the type, will result in the number being wrapped and something incorrect added.
For example, adding a byte of 300 will actually result in adding a byte of 35.
In Blue, the variable is not added and an error is generated instead.
Both Lacewing Relay Client and Server:
- Both extensions allow you to set your name to what it already is, even with no casing changes.
- Both extensions have expressions to get the Unsigned form of a 32-bit integer from a binary message, which Fusion promptly truncates to a Signed 32-bit integer.
(the expressions are kept in Blue for compatibility, although Fusion does the same thing with them)
- Both extensions have a length limit on welcome string that is undocumented, and silently cropped off.
- If you resize the binary to send to larger than it was, both extensions will not fill the new space with zeros, leaving whatever was in the memory before the expansion. Although, it is expected you will overwrite the extra space yourself with events.
Lacewing Relay Client:
- Relay Client will keep the welcome message of the last connection beyond the disconnect event.
- In Relay Client, reading the Received > Get text expression before a message is received will crash the application.
- Relay Client does not have any way of showing the server has disabled channel listing. If a Channel Listing Denied message is sent back, the Client will reset the channel listing to empty, but not trigger any events.
Lacewing Relay Server:
- Actions > Channel > Close channel has no effect.
- Actions > Client > Loop clients (with loop name) is missing entirely, despite conditions existing for a named client loop.
- Conditions > Message > "On <…> sent/blasted message to peer", the sender client is auto-selected, but the On interactive condition > Select receiver action actually re-selects the sender.
There does not appear to be a way to determine the receiving client during a peer message, limiting these events' usefulness considerably.
- Expressions > Client > Connection time (removed expression, menu item left in).
This expression was added back in again for Blue Server.
- Expressions > Client > Get client protocol implementation (removed expression, menu item left in).
This expression was added back in again for Blue Server.
- Relay Server will allow a client to change their name to different capitalization… unless the client is joined to any channels. Then it will deny the change with the reason "Name already taken".
Presumably, it scans channels that the renaming client is on for clients with the same name, and erroneously detects the renaming client as already using the name.
- Relay Server allows you to edit the channel name of a channel during a join request, resulting in the channel being joined as if it had the new name… but the existing peers on the channel will still see it as the old channel name.
The server will see the old channel as if it as renamed to the new name, and the channel listing will reflect that… so confusingly, there is a completely out-of-sync client and server channel names.
Read more about this bug under the action On interactive condition > Change channel name (for channel join request).
In Blue, editing the channel name causes the new channel name to be joined, not the old, so there is no incorrectly-synced issues.
- Relay Server allows you to set a client and a channel name that are blank, or end up being blank.
- In Relay Server, if a client requests a name set/channel join with a name that is longer than 256 characters, Relay will approve the request with seemingly the last 256 characters stripped – causing a seemingly blank name to be approved. 257 characters will result in a name of only the first character of the requested name, 258 result in 2 characters, and so on.
This essentially causes client instability, as when the peer list is sent to newly joining peers, Relay Client will misread the channel join message as the protocol only expects up to 256 characters in the channel/peer names. The peer count and peer names/IDs will be incorrect. In addition, on that channel the peer connect/disconnect messages will be ignored.
Blue Client will reject the broken channel join message, with error "Malformed message received (server error?). Message type 0 recognised but expected data was not found. Discarding message", and will not consider itself joined to the channel. Relay Server will still consider the Blue Client joined, though.
- There is no way to set local connection data, despite there being expressions to retrieve such data.
- Expressions > Guess MIME type for filename has an incorrect parameter list.
- Expressions > Statistics > Sent bytes expression is always 0.
- Expressions > Request > Get last modified time expression takes a parameter for some reason, but always returns 0 regardless.
Last modified time is a response, not a request header, and there is only one of those, so this expression is nonsense.
Source code bugs
- In all three, a memory leak occurs every time the IP addresses are checked against when a message is received. The memory leak is small, but very frequent in an active Relay Server, as it occurs for every UDP message, for each client, not just the sender.
- Relay Client has a UDP bug making it unable to connect to a second server, or reconnect to the same server after an unexpected disconnect.
- Relay Client uses a Windows socket-copying feature to check if a handle points to a socket. This makes Windows expect the application to use the copy, and so creates an unused socket that sticks around longer than the application needs it.
- Due to a bug with IP size checks, an IPv6 client cannot connect to Relay Server, as the IPs will not match properly.
- Relay Server has a random UDP shutdown, preventing new clients from connecting, at a random interval; the server may work for a few minutes, or even a couple of weeks, but will eventually cause any clients connecting to never succeed, but also never fail, so be stuck in limbo.
This is because the TCP connection still works, so the clients keep sending unreliable UDP message expecting a UDP response that they never receive; neither Client has a timeout programmed for this UDP.
Strangely, because commands like Name Set work over TCP, you can set a name and so on normally, even though On Connect has yet to trigger. This bug was finally isolated as a router keep-alive issue and fixed in Blue Server b19.
- The Webserver will often crash on app restart or close, if any connections are still active and sending data; which is very common as the Connection: Keep-Alive is the default for HTTP/1.1 and keeps connection open until the browser is not using any pages on the domain.
Interestingly, Webserver won't crash if you switch frame, even if the new frame doesn't have a Webserver in it. The content will keep being sent, even when there is no Webserver to finish sending it. However, it will still crash when you try to close the app from the new frame.
- Webserver's socket error messages include a line break frequently.
- Running Actions > HTTP > Host action twice rapidly with Webserver will result in a repeating error:
Socket error – Error accepting – The I/O operation has been aborted because of either a thread exit or an application request. (995)
Host should instead run a check for if it's already hosting, instead of letting the underlying system produce a confusing error.
Why are no Blue bugs listed here?
Blue is actively maintained, all bugs are fixed rapidly, often a bug is fixed and a new update pushed out the same day the bug is reported. So all the above bugs are fixed already.
If you suspect you have found a bug, read the How to debug your app topic in full. After showing you the steps to isolate and confirm the bug, the topic also says how to report it.
You can report both Blue and Relay bugs; although Relay bugs won't be fixed due to the loss of source code, they will be added to this help file to prevent other users wasting their time isolating the same bug you did.