Update on fixed frames, also multiple listener ports?

[dtermani]

Hey there, I have been researching lots of different networking solutions, trying to determine what I would like to use for my small online rpg and came across yours. I noticed network activity is tied to frames, is this not a bad idea instead of having network possibly run on its own thread or something like that?

Also, is it possible to have the server listen on multiple ports and then handle messages differently based on which incoming port is used? I wanted servers to interconnect on one port but then clients connect on another port and their messages of course would end up being handled appropriately. I was able to get this working for the most part using standard LiteNetLib by just making a second netmanager, but when I tried using this, I keep getting null reference errors in TinyNetScene.InternalUpdate().

Thanks!

[Saishy]

No, not really? You can put it on it's own thread but then I would recommend disabling unity physics simulation and calling simulate manually on your function.

Tying the network update to ticks allow you to implement client-side prediction and server reconciliation, which both needs a way to know at which point they are running their own simulation related to server.

For the second question, you would need to make a lot of changes on the base framework... That is the problem with a generic solution I guess.

[dtermani]

I got it working the way I needed it looks like, at least for the initial connection. I forgot the server was connecting as a client, so I needed to make it connect to both ports while testing that out. I won't be having the server connect to itself as it will be dedicated anyways, so I would not need that part to begin with.

It looks like TinyBird might work well with how my game framework works. I will have to test some more things to see. Essentially it is a clone of the Photon standalone server framework except I want it to be able to be hosted on a Linux server. I am not too far from that. Everything is, of course, sent via messages which end up being OperationRequests and Event messages which I will be serializing using MessagePack to a byte[], and then I just need to send them back and forth and then once deserialized converted by the frmaework I will end up with typically a Dictionary<byte, object> and a byte enum code which gets handled similar to how the NetManager does its switch/case setup.

I just need to figure out how to make TinyBird be able to send my byte arrays back and forth when needed and then my current framework can handle the rest. : D