New multiplayer transport release

Hi
New transport release has been published (based on 5.4.4f1 version)

http://beta.unity3d.com/download/42a153a956a9/public_download.html

The changes are:
0. few small bug fixes
1. ConnectonConfig.IsAckLong parameter doesn't exist anymore, instead there is new parameter ConnectionConfig.AcksType which can be set to
kAcks32, kAcks64, kAcks96, or kAcks128
so now buffer for reliable messages can contain 32, 64, 96, or 128 bits. (I would recommend to start from 32 and only if you expect difficulties with sending increase this parameter)
2. Experimental wss support (web sockets via ssl)
For confguration you should set following parameters in ConnectionConfig for web socket server:
SSLCertFilepath
SSLPrivateKeyFilepath
SSLCAFilepath -> could be null n this case certificate won't validate

I tested the last one with self-signed certificate and looks like everything works. Hence, im not sure that I cover all use cases. So if you fill that we need to implement something else, ping me please.
=========================================

Hi guys
two news
1. New transport will be officially realised in 5.6
2. the new version based on 5.4.3.f1 has been deployed

http://beta.unity3d.com/download/09aaef432c71/public_download.html

It contains new statistical functions and batch sending:
int GetIncomingMessageQueueSize ( hostId ) -- how many messages waiting for consuming (for host)

int GetOutgoingMessageQueueSize ( hodtId ) -- how many messages waiting for sending (for host)

int GetCurrentRTT ( int hostId, int connectionId, out byte error ) - current round trip time measured in the last ping period, NOT AWERAGED (per connection)

int GetIncommingPacketLoss -- ( int hostId, int connectionId, out byte error ) - how many incoming packet was lost in network (network packet drop count)

int GetIncommingPacketCount ( int hostId, int connectionId, out byte error ) -- how many packets have been sending to us (including lost packet): (for ex: from the start was sent 200 packets, where 10 packet was lost in transmitting)

int GetOutgoingPacketNetworkLostPercent ( int hostId, int connectionId, out byte error ) -- how many outgoing packet was lost in transmitting (I have sent 100 packet to somebody, 5% of them was lost while transmitting)

int GetOutgoingPacketOverflowLostPercent ( int hostId, int connectionId, out byte error ) -- how many outgoing packet was lost due incoming queue overfull (I have sent 100 packets, 7% of them was dropped by peer, because it has not get resources to handle them)

int GetMaxAllowedBandwidth ( int hostId, int connectionId, out byte error ) -- what is the current allowed bandwidth. (Initially I set up 1 MB per sec, but due big % overfull packet loss, library changed this value to 500kB/sec; 500kb/sec == MaxAllowedBandwidth)

int GetAckBufferCount( int hostId, int connectionId, out byte error ) -- how many slots in Acknowledged bugger have been occupied (my buffer size has 32 slots, current size is 31, most probably if i will send 2 reliable messages, second one will not send,
or, my AckBufferCountpersistently about 31, and I periodically get false while I send something -> I need change isAckLong to true )

int GetIncomingPacketCountForAllHosts( ) -- how many incoming packet was dropped due lack space in incoming queue (I receive 100 packet per sec, while read only one per sec, in 10 sec I will receive 1000 packets where 990 will be dropped)

int GetIncommingPacketCountForAllHosts () -- how many incoming packets I received (so far: from game start I received 100000 packets) (see this function name is not correlated with GetIncomingPacketDropNumber() name and possible should be changed)

bool QueueMessageForSending( int hostId, int connectionId, int channelId, byte[] buffer, int size, out byte error ) -- allow user to define when messages will be really sent out. By setting SendDelay to 0 and use this function, you can queue couple of messages for sending
and then send all of them in the moment when you really want. For example once per frame. This function insert messages in outgoing queue but don't really send

bool SendQueuedMessages( int hostId, int connectionId, out byte error ) -- this function really send messages, queued by SendBatched() function
===============
Hi guys the new version based on 5.4.2f2 has been deployed

http://beta.unity3d.com/download/ef3438090685/public_download.html

It contains following fixes:
1. Clean interface for websocket, now you can call AddWebsocketHost( ..., port, ...) if port != 0 host can use for passive and active connecting (port will be listening port) if port == 0, host can used for active connection only
2. Fixed bug with pool configuration
3. Fixed websocket bug when webgl can connect only to one host

===============
Hi guys

We have got news for you (But I’m not sure that news is exiting).


We have prepared an experimental build based on Unity 5.4.1p3 with a new multiplayer transport/library, which we’ll make available in the future release.

http://beta.unity3d.com/download/3966fa18f3c5/public_download.html

It contains the following changes with previous release:

1. Improved protocol
   1. Now, all reliable messages in packets will be combined in one, so with isAskLong = true, and frame rate 60 packet per sec you can sends messages without any headache up to connection with rtt = 1s.
   2. Message headers are significantly reduced, in many cases it is up to a 100% reduction
2. Send improving, with this release we can handle much more connection without performance degradation. When you call send you can expect that message will “almost” immediately will fired out. “Almost” means that there are 3 parameters that affect this process:
   1. GlobalConfig.ThreadAwakeTimeout (default value: 1ms), will regulate how often library will provide send operations
   2. ConnectionConfig.SendDelay (default value: 10 ms) defines how long library will wait for the next message before will send previous. It is useful to combine some messages in one packet.
   3. Bandwidth (see next section) if you exceed your bandwidth, message will wait before corresponding bandwidth will be available.
3. Bandwidth based flow control. In previous release used bandwidth could be calculated as packetSize*MinUpdateTimeout. In current library user can set up initial bandwidth by using ConnectionConfig.InitialBandwidth property (default value: 100mb/sec). Note: if your peer won’t have resources to handle this bandwidth it will reduced automatically by flow control mechanism.
4. Threading. For server platform (MacOS, Win and Linux) user can set how many worker threads will handle network related data (combine messages to packetd, extract messages from packets and so on) using GlobalConfig.ThreadPoolSize property. This improvement allow you to handle much more connections per server than before.
5. Experimental support for client web sockets: In previous version server platforms could host web socket server, now these platforms can not only be a web socket serer but they can active open web socket connection to another web socket server. After adding web socket host with function webSocketHostId = NetworkTransport.AddWebsocketHost() you can use NetworkTransport.Connect() function with webSocketHostId. This way Mac/Win/Linux can play with WebGL players.

You can run this build with your multiplayer projects without needing to make any changes to use these new improvements.

 

@vis2k , yes it makes sense

 

@Ashkan_gc
Will the WebSocket client work in mobile platforms too?
> it is manually prohibited right now as we do not tested them on mobile, but yes it should. When? I will try to unblock before unite, but cannot say I'm 100% sure

Is it possible to expose the raw Websocket as wel to be used without uNet protocol?
>afraid no..

Is it possible to reduce delay of websocket connections by any new configs? disabling nagle for example?
>Nagle has been already disable, enabling it bug will require time For delay you will still have 2ms read/write delay for each peer (it is pulling model right now, every TreadAwakeTimeout unet pulling ws service... To change this will require time...

 

Oh my god.. Yes you are right will fix today, new build will be available on the next week. thanks a lot. It is not very important right now, as performance should be enough with one thread but in future it can be problem.

I think I will fair warning if thread pooling is used for not proper platform and will change this value to 1.

 

@Ashkan_gc Im working on this right now. Hope it will be ready before end of the next week

 

@Ashkan_gc delayed I did try on last week, unfortunately no success, will ask help android and ios team on this week, but it will take a time.

@peterpi If you do not fill problems, probably you are ok. The problem can happened when you use couple of reliable channels and sends data to all of them + latency ~100-150 loss. In this case retrasmit buffer can be be easily overfilled and you won't be able to send... In this release all reliable message will be combined in one doesn't matter which channel they are belong...

 

@PhilSA: good question. Road map I hope will be published by Erik during Unite. For me, as I'm usually working on LLAPI it is difficult to comment the list As far as I know (i can be wrong) inheritance issue is in work right now...

@Meneu, sorry man, cannot understand you. Do you need connect to Unet from other (not unity application)? Or you need to know protocol internals?
if first, you need to ask any unity support engineer to access to "server.dll" unet project. (Unfortunately I don't know all of the requirements to get access to them). If second, you need wait for unite where I will most probably represent protocol internals.

 

@Meneu ok, you will need to connect with support engineer and ask him can you access to server.dll unet code. If you cannot do this, send me private message and I will try to check what is procedure is.

 

What we have coming out in the immediate future is this new network transport impolementation (this is a huge change internally), and this is also bringing better websocket support on non-webgl platforms. Then there are improvements on the dashboard coming out any day now and more are in the pipeline and we'll put them out as soon as they are stable. More features are on the roadmap where work has started, like NAT punchthrough support, relay host migration support and server DLL support but I don't have an ETA on those shipping to the public. However, we've focusing more on bugs, stability fixes and documentation improvements and will do that until those are in a good state. When stuff like the new transport and dashboard improvements are done we'll rather work more on bugs, rather than adding other shinty features (besides the ones listed here), at least until we're happy with the foundation.

The inheritance issues you mention are on our list, and we'll get to them, this isn't related to this new transport effort though, this is low level transport (C++) while the inheritance issues are in the high level (C#). So don't expect it fixed in this build or with this feature but they will be addressed in our bug squashing efforts.

 

@Whippets Correct. Considering message flow:
m1, m2, m3, m4, m5, ...., mx, lets say that length of each message ~ 1/3 PacketSize (so 3 message can be combined in the packet) and let you send 10 messages per frame, frame length 10 ms (each 1 ms), SendDelay = 5 ms.

When worker thread will receive first message it will wait for a 5 ms to trying combine more than one message per packet. In this 5 ms we will receive 5 messages. Thread will combine them in two packet P1(m1, m2, m3) and P2(m4, m5) and then will send two packet out. As incoming queue is empty, thread will fall asleep again. When m6 message will arrive worker will consider them as first message in sequence and will wait for SendDelay again...

Note: every time when worker added message to packet it will check current occupied bandwidth. If bandwidth will overfull thread will wait before bandwidth will be enough to send next message in the queue. For example
Initial bandwidth is 10kb per sec, in the last second you want send 11k. the first 10K will send while remaining 1K will wait for 1K/10K/per sec ~0.1 sec...

 

@Whippets SendDelay def value is 10 ms, if you won't touch anything you will have 10 ms gap to accumulate messages.

@Jouni-Mannonen
1. Hope it will 5.6, I will notify here when we will understand the date
2. New 5.4 version based on the next path will publish here on the next week (I still need backport one more bug fix, merge with 5.4 branch, and go through qa process I think it will be Tuesday or Wednesday
3. I don't understand the last question about networking DLL ? What do you mean?

 

Not yet. We are working on modules in unity (when each library or component will be separated) but this work far away from finish

For this release of UNET we decided just support all official patches with new UNET implementation before official release. The main reason of this - from our experience alpha-beta period is not enough for multiplayer testing, and we had a lot of bugs just after release and got stuck with them. Now (I hope) the product is much more stable (1) and we have time to fix bugs in experimental release (here) faster and be closer to customers...

 

@Jouni-Mannonen No, I don't think so. SendDelay (as other new parameters) has def value sj you don't need to set them with old projects. Second SendDelay (as other new parameters) is not parameter which crc calculated, so old code should work with new perfectly. For new library we tested unet with old legacy hlapi code, nothing changed. We don't change old function just add new ones..


@Whippets It always belongs to ConnectionConfig as other parameters which you configure via NetworkManager, NetworkManager is hlapi artifact and it hides llapi code inside.

 

@Whippets I meant that SenDelay has default value in ConnectionConfig constructor. If you do not set them explicitly it will remaining default...

 

@Whippets So far no, no new configuration parameters have been exposed to HLAPI yet. The reason is easy, we will probably add or remove some of them and do not want to do this work twice... So far you can (1) do not tuch these parameters and use NetworkManager and so on as is (with default values) or use customconfig and define these parameters there.

@Bitiquinho Good question,
(1) i haven't get any notes, requests, bugs about multicast for the year
(2) There is a logical problem with "multicast" sending: You send mulitcast message to connections 1,2,3,4,5, what are you expect if connection 3 is disconnected and connection 4 is overfilled?
(3) What you can save with multicast it is only one memcpy per message. So for 10 connection you will save 9 memcpy, Im not sure (now) is it significant improvement or not..
(4) On c# level you can easily get the same result + add your logic to handle situation like described in 2.

So, based on these facts I (temporary?) exclude multicast from code, so code going to be much cleaner.
BUT! Probably im wrong with my assumptions. So if you can prove existence of this feature in library i will implement them.

 

You could look at the layers like this, from lowest to highest, the highest depends on what's beneath it, but not reversed.

• NetworkTransport - bare bones socket functionality
• NetworkClient and NetworkServerSimple - client/server classes which can be used for anything, can set up connectivity and message handlers but nothing more complicated than that.
• NetworkServer and ClientScene (with NetworkClient) - these use scene data and add more functionality, so can spawn prefabs, track server/client objects and so on.
• NetworkManager and NetworkManagerHUD - more ready to use functionality so you can get started with minimal code, common functionality exposed in inspector, easiest way to set up connectivity and spawn players/objects.
• NetworkManagerLobby - built on top of the network manager to provide lobby functionality (people connect and join a lobby scene and game starts when everyone is ready).

You can for example skip using the NetworkManager and implement that functionality yourself, then you would use NetworkServer with NetworkClient/ClientScene and ignore the manager altogether.

 

@perplex_bcn we will try to solve this before end of november. Cannot say exactly when as the time of solution depends not only from us. Yes I know about this pain, not only you asked about this feature...

But I have the similar question. If we will implement this fast can I hope that you will test this solution and report about any problem immediately? In opposite case I will ask qa play with this solution first, and it will require much more time

 

Ok, so yes, right now in this build this feature just disabled. (in llapi but you can still write the code for handling this on user level)

i will change my question. What do you expect from this feature, how it should work? If we are going to implement this feature as one of the core functionality? (take into account the fact that gain which we receive == 1 memcpy per one Send() call in user thread.

 

@Bitiquinho Looks like we are talking about different things. Do you mean real multicasting? As bsd socket multicast, correct?

Because, the "fake" multicast was implemented, means that you can send message to the connection group like this:
PrepareSendMulticast(buff[]); //prepare buffer make interdomain memcpy;
SendMulticast(connection1); //send this buff (no copy) (sendto(socaddr*)); generic unicast sending inside
SendMulticast(connection2);//send this buff (no copy)
SendMulticast(connection3);//send this buff (no copy)
SendMulticast(connection4);//send this buff (no copy)
FinisgSendMulticast(); //free resources...

 

Hi guys the new version based on 5.4.2f2 has been deployed

http://beta.unity3d.com/download/ef3438090685/public_download.html

It contains following fixes:
1. Clean interface for websocket, now you can call AddWebsocketHost( ..., port, ...) if port != 0 host can use for passive and active connecting (port will be listening port) if port == 0, host can used for active connection only
2. Fixed bug with pool configuration
3. Fixed websocket bug when webgl can connect only to one host

 

@jjobby try please the last version, i did check it, i can compile ...