UNET stats methods are not implemented?

Unity Engine
,
1

NetworkServer.GetStatsIn()
NetworkServer.GetStatsOut()
NetworkClient.GetStatsIn()
NetworkClient.GetStatsOut()
methods are always return 0. I’ve found some thread assuming that they are not implemented in favor of future network profiles, but I failed to find any other mentions of that.

Also NetworkTransport.GetPacketReceivedRate and NetworkTransport.GetPacketSendRate methods return values from 0 to 30 bytes which are certainly not valid.

Does anyone has any clues on the problem?

2

Look at the network panels of the Unity profiler for better info.

3

That’s good, but I still want to know send/receive rate and also output some simple stats in built players without attached profiler. I’m also confused: isn’t those profiles implemented with the same API or they use some internal engine functionality?

4

Did you ever figure this out? I am trying to implement some reporting for players to get the stats of their connections. On 5.3, NetworkServer.GetStatsIn returns 0.

5

No, we ended up using custom protocol on top of NetworkTransport

6

I was trying to use this method today, is this still not implemented? Why is it still left in the code? At the very least least a note in the documentation would have saved me quite a bit of time trying to figure out why this wasn’t working.

7

Stumbled on the exact same issue, lost about an hour or so to this.

@seanr , some documentation on this would be fantastic. (Simply a “Reserved for future use”)

8

Lost time on this too. Can we have this resolved soon please? Its not a major problem, but this issue is costing me and others time.

9

Just lost a half hour on this - and will lose more developing my own workaround…

10

Apologies that this has gone on so long without a reply. These methods are currently not active. I’m working with the team to figure out how to provide this data. In the meantime we’ll be looking at adjusting the documentation to clearly identify their state and likely remove them in future releases until we have a solution that you all can use. I know that doesn’t help you if you currently need that info but at least it should reduce confusion when you go to use something and it simply doesn’t work.

Also, I want to point out that some of the stats that these methods were set to provide are in the profiler. For example you can use the profiler to see the number of messages. We’ll be looking to extend the profiler to provide the stats you guys need to be successful. Please feel free to provide any thoughts you have on this and the data you feel you need.

11

Quick correction. The following is coming in an upcoming 5.6 patch release:

  • GetIncomingMessageQueueSize - how many messages waiting for consuming (for host)
  • GetOutgoingMessageQueueSize - how many messages waiting for sending (for host)
  • GetCurrentRTT - current round trip time measured in the last ping period, NOT AVERAGED (per connection)
  • GetIncommingPacketLoss - how many incoming packets were lost in network (network packet drop count)
  • GetIncommingPacketCount - how many packets have been sent to us (including lost packet): (for ex: from the start sent 200 packets, where 10 packets were lost in transmitting)
  • GetOutgoingPacketNetworkLostPercent - how many outgoing packet were lost in transmitting (I have sent 100 packets to somebody, 5% of them were lost while transmitting)
  • GetOutgoingPacketOverflowLostPercent - how many outgoing packets were lost due incoming queue overfull (I have sent 100 packets, 7% of them were dropped by peer, because it does not have resources to handle them)
  • GetMaxAllowedBandwidth - what is the current allowed bandwidth. (Initially I set up 1 MB per sec, but due to big % overfull packet loss, library changed this value to 500kB/sec; 500kb/sec == MaxAllowedBandwidth)
  • GetAckBufferCount - how many slots in Acknowledged buffer have been occupied (my buffer size has 32 slots, current size is 31, most probably if I 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 )
  • GetIncomingPacketCountForAllHosts - how many incoming packets were dropped due lack space in incoming queue (I receive 100 packets per sec, while I read only one per sec, in 10 sec I will receive 1000 packets where 990 will be dropped)
  • 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)

We’re currently investigating ways in which we can make this data easier to view and access but wanted to get the functions out to unblock anyone that needs this information. As I noted in my post above we still need to properly highlight that the GetStatsIn/Out functions are currently non-functioning and are likely to be removed in favor of the methods I listed above.

On that note we’d love to get feedback on what data you feel you need that the methods above don’t provide.

1 Like
12

Thanks for the detailed update!

My use-case involves sending larger-than-normal amounts of data through HLAPI’s messaging system. I’ve come up with a basic system for splitting / reassembling the data between server and client, but the buffer occasionally fills up and drops chunks. Without these functions I couldn’t see any easy way to detect its status / yield when it’s full.

The functions you’ve described sound like they should give me what I’m after, but seeing as we’re on the topic - I think it would be valuable for Unity to include some sort of large message support out of the box (unless it’s already there and I’ve missed something?). Either that, or perhaps some sort of SendMessage queue which automatically adds queued messages into the buffer as slots free up.

Beyond that, I don’t suppose you’re able to give any rough ETA on when that patch might go out - be it days? weeks? months? I’m trying to assess whether it’s worth investing time in developing my own solution in the meantime.

Cheers!

13

Check please any from “Fragmented” qos (reliable fragmented or unreliable fragmented) it will disassembly/reassembly large messages. Do not forget tho change ConnectionConfig.FragmentSize to be 80% of PacketSize which you use, and switch please to the last version if it possoble

14

I’m using a reliable fragmented channel, but I think the data I’m sending is still too large for it - i.e. typically it’ll be in the range of 5-10mb, though the system needs to be able to handle potentially 100+ mb. Is SendMessage supposed to be able to function with such large amounts of data?

15

Definitely no :frowning: I’m working on the solution of this problem, but it still my hobby project, so i cannot say when it will be ready. (it will take more that 2 month i think)

16

With regards to the patch, I can’t provide an exact date but it will be on the scale of weeks not days or months.

17

Thank you both for your replies, I’ll keep all that in mind!

18

@HadynTheHuman - Just wanted to follow up and let you know that the patch release came out on 18th and can be found here: Download Archive

If you get a chance to use it and the new methods I’d love to hear your feedback.

1 Like
19

Thanks for keeping me posted - really appreciate it! It might be a few days before I have the chance to look into it, but I’ll be sure to let you know how I go :slight_smile:

20

I’m still getting zero’s. Can you confirm im using it correctly.

called from InvokeRepeating.

private void UpdateServerStats()
{
NetworkServer.GetStatsIn(out _serverMsgInCount, out _serverMsgInBytes);
NetworkServer.GetStatsOut(out _serverMsgOutCount, out _serverMsgOutBufferedCount, out _serverMsgOutBytes, out _serverMsgOutBufferedPerSecond);

Debug.Log("Server Total In Bytes : " + _serverMsgInBytes + " Server Total Out Bytes : " + _serverMsgOutBytes);
}