Sending a message uses TCP (Transmission Control Protocol) whereas Blasting a message uses UDP (User Datagram Protocol).

Both are common low-level protocols used around the internet; for example, the website protocol HTTP used by web browsers is actually built on top of TCP, which in turn is built on top of IP.

In Lacewing, briefly explained, TCP (Send actions) are used for guaranteed, received-in-same-order-as-sent messages, whereas UDP (Blast actions) are used for fast, unreliable messages.


If you transmit too much data along an internet route, any device (sender, router, receiver, etc) has to handle that.

If the connection is overloaded, and new data is being sent, protocols respond different ways:

  • A TCP data packet will be queued, and sent as soon as possible, meaning it arrives with quite a bit of delay, up to several seconds late – any later would result in a timeout and the connection being closed.
    You either get all the messages, or you get a disconnect.
  • In UDP, data packet queuing is far less likely due to the loss of speed it would cause, so the data will just be discarded. UDP is called "connection-less" protocol because it doesn't have a formal setup like TCP, and can be inactive without closing down.
    But in practice, routers set up pass-through UDP routes that require a UDP message every 30 seconds to every 300 seconds, depending on router. This keep-alive activity is handled in Bluewing automatically as of build 19, but beware Relay will drop UDP entirely, seemingly at random.

Whereas TCP messages are guaranteed to make it to their destination alive and in the same order they were sent, UDP messages are not. Sometimes, a UDP message can be dropped, or it can arrive out of order; very rarely, it can even be duplicated, so the same message received twice.

You must design UDP as if messages will be dropped, because even in the best conditions, UDP will still lose a small fraction of messages (below 1%). Either design it so the UDP is re-sent if missing after a period of time, or design it so the missing message will not matter.

Generally you would Send a message with TCP if it was a chat message, whereas you would Blast messages with UDP if they were position updates for an object. Object positions need to update quickly for the game to be playable. If a message is dropped or sent out of order, it will often be fixed in no time because you are sending so many so fast.

If you decide to only send messages when said object starts or stops moving, you should take precautions and make sure the last message is Sent and not Blasted to guarantee that it is in the correct spot when standing still.