About this asset
Support
Thank you for buying our asset.
Unfortunately sometimes customers leave negative ratings and complain about things not working without contacting us so we can not help or fix the issue. We want to provide good support and have our customers having a great time developing their content, so:
If you happen to encounter any issues, please write an email to assets@firesplash.de and we will be happy to help!
Also you would do us a big favor, if you'd leave a review on the asset store, once you got some experience with the asset. Thank you!
Setup and architecture
This asset is an implementation of the Socket.IO protocol version 3 and 4 designed for Unity It works quite straight-forward: Just create a GameObject and add the "Socket IO Communicator" component to it. Enter all details used for connecting into the fields. The Address has to be provided without protocol prefix and in most cases without any folders. Socket.IO-Namespaces and Acknowledgement are not supported by the BASIC library. See more information in the feature matrix below.
Version compatibility
| Server v1 | Server v2 | Server v3 | Server v3.1 | Server v4 | |
|---|---|---|---|---|---|
| Socket.IO Client for Unity v2 | No | Yes | No | Partial* | No |
| Socket.IO Client for Unity v3/v4 BASIC | No | No | Yes | Yes | Yes |
| Socket.IO Client for Unity v4 PLUS | No | No | Yes | Yes | Yes |
*) Partial means that a compatibility mode must be enabled on server side which actually makes the server act like a V2 server. This means it has no V3 benefits. It would be the same as if you ran a v2 server. This is only meant for transitioning to V3.
This table does only cover our assets. There are many other solutions available, some don't work on WebGL at all, some use deprecated APIs. Some are over-aged. Our assets are made FOR Unity, not only WITH Unity. This means every feature was designed having Unity in mind regarding thread safety, saving framerate, WebGL support etc.
Backwards Compatibility Note / Warning
One might ask: If your Socket.IO asset v2 is compatible to Socket.IO Server v4, why was this still a good investment? Why the higher price? The Socket.IO v2 asset only covers the very basic portions of the protocol in native mode. For example reconnects are not automated, most of the status events are not emitted to your application and after all the compatibility layer is not a future-safe investment. This Asset version implements the most important events (reconnect, connect_error, reconnect_error and so on) as well as auto reconnecting. Further Socket.IO v3/v4 has a way better timeout/ping handling and is considered more stable. This is only the case when both sides are v3/v4 The higher price is applied as v3/v4 support needed huge changes in the code base and lots of research. The undelaying protocol has significantly changed since v2 which is also the reason why v2 and v3/v4 are not compatible (without the compatibility flag which actually degrades v3/v4 servers to v2) After all we provide our customers a discounted upgrade/downgrade path, so at any time customers will only pay the extra work, and do not have to buy a complete second asset.
Differences between Basic and Plus Client
Our two current Socket.IO assets are completely independed code bases. While both provide a way to connect to Socket.IO Servers (Version 3 or higher), their implementation is completely different. For simple applications, the BASIC variant might be enough, while the PLUS variant provides the maximum flexibility and a way larger feature set and an implementation which is near 100% consistent between WebGL and Native as we entirely re-implemented the whole protocol on top of plain Websockets.
The main difference is, that the Basic variant only supports a single payload, no binary messages and always returns a JSON string for events. The PLUS variant works with objects, supporting even binary payloads and more than one payload per event. It does not deliver a JSON representation but always parsed objects.
Code difference
A simple fictive case would be to receive an event, containing a position of an object and then updating the location locally.
The following example shows the simplest possible implementation with the respective asset, without using special or higher features.
For the example, we assume we got a handle to the object in "remoteObj", all server settings are configured in the components using the inspector, and...
...using this BASIC asset...
...we got a reference to the SocketIOCommunicator (from the basic asset) in "sioCom":
void Start() {
sioCom.Instance.On("ObjectMoved", (payloadJson) => {
Vector3 newPos = JsonUtility.FromJson<Vector3>(payloadJson);
remoteObj.transform.position = newPos;
});
sioCom.Instance.Connect();
}
...using the PLUS asset...
...we got a handle to the SocketIOClient (from the PLUS asset) in "io":
void Start() {
io.D.On<Vector3>("ObjectMoved", (newPos) => {
remoteObj.transform.position = newPos;
});
io.Connect();
}
Feature Matrix
| Socket.IO Client V2 | Socket.IO Client V3/V4 BASIC | Socket.IO Client V4 PLUS | |
|---|---|---|---|
| TRANSPORT FEATURES | |||
| SSL/TLS Support | Yes | Yes | Yes |
| Websocket Transport | Yes | Yes | Yes |
| Long-Polling | No | No | No |
| Set custom path | Yes | Yes | Yes |
| Custom Parser/Adapter | No | No | Experimental (Must be implemented by yourself. Not recommended) |
| Multiple Instances (Connect to multiple servers) |
Yes | Yes | Yes |
| SUPPORTED PLATFORMS | |||
| Windows, Linux, MacOS | Yes | Yes | Yes |
| Android, iOS | Yes | Yes | Yes |
| WebGL | Yes | Yes | Yes |
| Console platforms | Assumed yes¹ | Assumed yes¹ | Assumed yes¹ |
| SOCKET.IO FEATURES | |||
| Connect Default Namespace ("/") | Yes | Yes | Yes |
| Connect Additional Namespaces (Multiplexing) |
No | No | Yes |
| Event-Specific Callbacks (On/Off) | Yes | Yes | Yes |
| CatchAll-Callbacks (OnAny/OffAny) | No | Yes² | Yes |
| Authentication payloads | No | Yes, static | Yes, per Namespace (using a delegate) |
| Binary Payloads | No | No | Yes |
| Object Payloads | Manually serialized | Manually serialized | Yes³ |
| Multiple Payloads | No | No | Yes |
| Acknowledgements | No | No | Yes |
| IMPLEMENTATION FEATURES | |||
| Delay-Free, threaded delegate | No | No | Yes⁴ |
| Using UnityEvent for common Callbacks |
No (delegate) | No (delegate) | Yes |
¹) We don't see any reason why it should not work but we are not able to verify this. Consoles might add legal or technical restrictions. Referr to your agreements and technical descriptions.
²) Implementation can slightly differ from the Socket.IO standard as well as between WebGL and Native builds.
³) Only objects, that can be serialized using Json.Net
⁴) Normal EventHandlers are called using a dispatcher loop. this is required to safely run them on the main thread. This causes a delay of usually one frame between receiption and callback. "Delay-Free callbacks" are delegates that get invoked immediately when an event comes in on the socket, but in native builds they get called from the receiver thread so the delegate is NOT executed on the main thread. This is only for advanced programmers, because you need to mind thread safety. In WebGL builds they are also delayed technically. This can not be changed.
Correct Seat License Count
Officially you need to buy a seat license in the asset store for any unity user working with the asset. As this is not an editor asset but a "game asset" it is hard to determine how many seats you need, right? We are always trying to make our assets affordable and still rock solid. We ask our customers to be fair players and buy licenses according to the actual usage and revenue. Here is a guideline:
For independent developers up to 5 team members working on your game (in total) and in compliance to the revenue terms of Unity "Free"...
...we allow using this asset with a single seat license for unlimited projects as long as you comply with the revenue terms for Unity "Free" (no matter if you are actually uisng Plus for some reason, Pro and Enterprise excluded). We do only count people working on the game (artists, developers, game designer, ...). If you hire IT specialists, marketing etc they do not count.
For bigger independent dev teams, if you don't comply to the Unity Free license terms as a small team or if you are using Unity Pro or Enterprise...
...we ask you to buy one license per team member who works on your project (in Unity).
For big studios and any enterprise licensee
...we assume you are making a lot of money with your games. Great! While the license requirements still are met with one license per unity user, we kindly request you to buy one seat per unity user or per project using our asset depending on what count is higher.
Frequently Asked Questions
Please click here
