This extension lets you communicate directly with most WebSocket servers. This is the protocol that things like cloud variables and Cloudlink use.

These are rather low level blocks. They let you establish the connection, but your project still needs to know what kinds of messages to send and how to read messages from the server.


connect to [wss://...] :: #307eff

You have to run this block before any of the other blocks can do anything. You need to provide a valid WebSocket URL.

The URL should start with ws:// or wss://. For security reasons, ws:// URLs will usually only work if the WebSocket is running on your computer (for example, ws://localhost:8000).

Something simple to play with is the echo server: wss://echoserver.redman13.repl.co. Any message you send to it, it'll send right back to you.

Note that connections are per sprite. Each sprite (or clone) can connect to one server at a time. Multiple sprites can connect to the same or different servers as much as your computer allows, but note those will all be separate connections.

when connected :: hat #307eff

<is connected? :: #307eff >

Connecting to the server can take some time. Use these blocks to know when the connection was successful. After this, you can start sending and receiving messages.

When the connection is lost, any blocks under the hat will also be stopped.

when message received :: hat #307eff

(received message data :: #307eff)

These blocks let you receive messages from the server. The hat block block will run once for each message the server sends with the data stored in the round reporter block.

Note that WebSocket supports two types of messages:

If multiple messages are received in a single frame or if your message processing logic causes delays (for example, using wait blocks), messages after the first one will be placed in a queue. Once your script finishes, if there's anything in the queue, the "when message received" block will run again the next frame.

send message (...) :: #307eff

This is the other side: it lets you send messages to the server. Only text messages are supported; binary messages are not yet supported.

There's no queue this time. The messages are sent over as fast as your internet connection and the server will allow.

when connection closes :: hat #307eff

<is connection closed? :: #307eff>

These let you detect when either the server closes the connection or your project closes the connection. They don't distinguish. Note that connections have separate blocks.

Servers can close connections for a lot of reasons: perhaps it's restarting, or perhaps your project tried to do something the server didn't like.

(closing code :: #307eff)

(closing message :: #307eff)

These blocks can help you gain some insight. Closing code is a number from the WebSocket protocol. There is a big table of possible values, but generally there is very little to gain from looking at these.

Servers can also send a text "reason" when they close the connection, although almost no servers actually do this.

close connection :: #307eff

close connection with code (1000) :: #307eff

close connection with reason (...) and code (1000) :: #307eff

Your project can also close the connection whenever it wants. All of these blocks do basically the same thing.

Just like how the server can send a code and a reason when it closes the connection, you can send those to the server. Note some limitations:

when connection errors :: hat #307eff

<is connection errored? :: #307eff>

Sometimes things don't go so well. Maybe your internet connection died, the server is down, or you typed in the wrong URL. There's a lot of things that can go wrong. These let you try to handle that.

Unfortunately we can't give much insight as to what caused the errors. Your browser tells us very little, but even if it did give us more information, it probably wouldn't be very helpful.

A connection can either close or error; it won't do both.