WuKongEasySDK

WuKongEasySDK provides lightweight connection, online messaging, and event APIs. Your application owns the backend and UI; the SDK authenticates with WebSocket JSON-RPC CONNECT and exchanges messages. Choose a platform below. Use the official examples to prepare a server and test accounts.

Choose a platform and send the first message

Does it fit your application?

EasySDK is neither a chat UI nor a complete product backend. A successful send means the server returned a send result; it does not mean the peer received, displayed, or processed the message. If you need the broader feature set, return to SDK selection.

Rust uses one Client per identity; clones share the socket. subscribe() returns a bounded receiver, disconnect().await permits later connection, and destroy().await closes permanently. The default device category is PC 2. See the Rust quickstart for installation and lifecycle.

Three concepts to start with

Channel is the message destination. A person message targets the other user’s UID; a group message targets a group ID created by your backend.

Payload is your application’s JSON content, such as {"type":1,"content":"Hello"}. Received content belongs in your UI or application handler.

Send result is the server’s processing result. It differs from recipient delivery and a read receipt. Check both the sender’s result and the recipient’s event during your first integration.

Prepare connection credentials

The client must not create its own identity or call Product HTTP management routes. After product login, the trusted backend returns the minimum connection material over HTTPS:

{
  "uid": "alice",
  "token": "short-lived-token",
  "websocketUrl": "wss://im.example.com/ws"
}

Complete Authentication & Tokens first. The default composition exactly matches each CONNECT token against the /user/token record for the same UID and device category. Your deployment must still protect that route, implement expiry and rotation policy, and prove that invalid, revoked, and product-expired tokens are rejected.

Run Alice and Bob

All platforms follow the same minimal path:

1. Obtain separate uid, short-lived token, and websocketUrl values for Alice and Bob.
2. Create the clients in two independent devices, processes, or browser contexts by following the platform quickstart.
3. After both sides report a successful connection, have Alice send a text JSON payload to the person Channel bob.
4. Retain Alice's send result; on Bob, verify fromUid, the Channel, and the payload in the realtime message event.
5. Send from Bob to Alice and prove the reverse direction.
6. Leave the page or sign out, remove listeners, and disconnect; confirm there is no duplicate event or background connection.

This loop verifies online messaging only. Send acknowledgement, realtime receipt, and product completion are three different states; model them with Messaging.

To validate the environment first, follow Run the Official Examples with the verified server and client revisions before moving tutorial code into your application.

Release resources on exit

An application object usually owns the connection. Pages remove their own subscriptions; account logout releases the connection. Follow each platform’s singleton, threading, and reconnect rules.

Versions and compatibility

Tutorials pin the versions above for reproducibility and troubleshooting. Web 2.0.5 includes a handshake-failure reconnect repair; see its release notes. C++ uses the WuKongIM custom registry or a prebuilt archive matching your system.

The first task is online bidirectional messaging. Reconnect does not fetch offline history or automatically select another node. Cluster recovery and membership updates also depend on the server version. Exact historical environments, passing results, and failures remain in engineering validation records.

Next

Run an official example → follow your platform tutorial → check both message directions → use production checks for actual devices, WSS, Token rotation, and recovery.