Sign In Register

How can we help you today?

Start a new topic

Only reliable (TCP) packets being received in any occasion

Hey. I created a wrapper around the Real-Time services for Unity that makes it work like UNET/Photon and I'm currently facing a limitation I posposed after first noticing it early in the project.

When sending data to sync scripts' variables between players, Unreliable and Unreliable-Sequenced packets never arrive. Not even once. But (surprisingly in this case) when using Reliable they arrive and the variables are synced normally.

 The relevant code I'm talking about is as follows: 

using (RTData data = RTData.Get ()) {
	// Adds the SparkStream with the changed variables
	data.SetString (1, SparkExtensions.Serialize (this));

	// Adds the SparkMessageInfo with sender and details
	data.SetString (2, SparkExtensions.Serialize (info));

	// The SparkBehaviour's ID that will be updated on the receivers
	data.SetInt (3, behaviourIndex);

	SparkManager.instance.sparkNetwork.SendData (1, GameSparksRT.DeliveryIntent.RELIABLE, data);

Other relevant information is that I'm using Json.NET to serialize data structures. I'm unaware of a method to find out how much bytes the packets are using but I feel this shouldn't be relevant in the case of Reliable packets arriving.

It's unfortunate this topic is 2 months old and no one has bothered to provide a suggestion or answer.

Actually , I came across a similar issue as well. In my case, TCP and UDP  are all both needed ,but every now and then , the UDP channel stop recieving data at all while the TCP data sending is fine.

   After days of investigation, I found that if the UDP data started to send continuosly as soon as connection is established, the UDP connection will has much better chance to be working fine,otherwise, if you only start to send data through UDP when the data needs to send(lets say 30 seconds later),the UDP connection stops working almost surely.

    So my solution so far is simply just by keeping the data sending through the UDP, that prevents the connection from "halt down" in most time, but this might not be the final solution, as the reason of how this way works is still unknown.

Login to post a comment