There's no "speed up" in NIO vs IO in terms of ping per se - the performance gain is primarily in scale. It's like dealing cards in a poker game. Blocking IO is like dealing 5 cards to player A, then dealing 5 cards to player B etc while non-blocking is like dealing 1 card to Player A, then 1 card to player B etc until everyone has 5 cards. Sort of anyway.
I don't get the analogy. I think what you describe is two different types of multiplexing. Blocking is waiting for someone to text you back and texting back immediately while holding a text message conversation with them. Non-blocking is putting the phone on silent, using the internet while you wait and checking for new messages whenever you feel like it.
Someone needs to be in control in some way for proper synchronization. You can get away with what you're doing if you add someone (The Server best choice) to at least keep score of the time or more specifically, the time step (this also requires a fixed time step for logic/updates).
That's not really true. If you have a game with two players and a pre-established connection, then synchronization is trivial. Just send state changes and acknowledgements for each player. There is no server in that scenario. Extending it to more players is just adding a client to the network. Peer to peer RTS games with more than two players was done in early multiplayer RTS games, back when players had worse internet connections and computers.
Others say it only increases performance on large file transfers and others say it doesnt increase performance at all, but rather makes it more scaleable. The only advantage that i can see is the non blocking write and reading. And it has a channel selection.
That is exactly what NIO gives you. It won't have an effect on network transfer speeds. (Latency or throughput) Network speeds are much slower than local data processing, so it is not a bottleneck. Just remember to flush packets. If you use TCP then they will be buffered at each router along the network path. TCP also creates lag be require all lost packets to be resubmit even if they are redundant or outdated.
Well it is a RTS. so synchronisation errors are a big thing that i'm trying to avoid.
As soon as an entity reaches a node i let everybody know so they can interpolate if the entity isn't there quite yet. I think this might be a problem since at the moment i'm using the delta time for movement, and i'm afraid that if you have a slower computer that your unit might end up somewhere later or something.
I'm thinking of changing the movement so that units will move everytime they receive an update packet from the server. This way your units will only be behind your lagg, but this requires a heavy amount of data though. Also i'm definitely using tcp so the packets will always arrive in correct order.
As for the server, i try to do as few calculations on it as possible. It should just be a link that all the players can communicate with each other with a very low level of cheating prevention (checking your resources if you want to make a unit, if you dont have enough no new unit creation packet will be send).
Determinism is essential to synchronization. Small differences mean the synchronization is lost. If there is no way to detect or prevent it then it will snowball into much bigger differences and cause worse problems. You may use fixed time steps for game state updates so that all players make the same updates. You can still use interpolation for graphics because from the program's point of view that is just cosmetic. Rendering should be separate from logic in a well designed game. Determinism means the same input creates the same output. Iff players are synchronized they have the same game state. If they receive the same instructions and process them the same way, a deterministic process will give them the same output. If synchronized players make the same deterministic updates, they remain synchronized at the end of the update. Problem (mostly) solved. (The trick is making sure everyone has the update instructions.)
So if you want that are synchronized to stay synchronized after processing other players' commands, you wait until everyone receives an update and make sure they all get the same thing. I think this requires an ack system, which TCP uses but you will want to make your own anyway. Meaning you should use UDP.
You want the game to make updates at a fixed rate. 10 to 20 is enough for an RTS game. Lower might be possible. Higher may or may not be better but will be harder to accomplish reliably. If you do this, you will give every player enough time to make computations and reduce network speed requirements. Meaning fast or slow computers and fast or slow connections can participate.
Know that you will never prevent cheating. You can prevent many hacks by using synchronization with or without a server with no extra work. You won't be able to prevent players from seeing more than they are intended to see (reveal enemy spies hacks), but will your players have the incentive to do that? You could also use a telephone to coordinate with an ally, share a computer lab with your teammate, have a friend hover over your shoulder to point out things you miss, or get your grandparent to play on your behalf. Some people call this cheating, others don't. Having unbalanced weapons or glitches will be worse for you than these cheats. If you think you need a server to prevent cheats, you do not have a good synchronization system. Your server's ability to prevent cheats is only as good as the synchronization system. If you have a "prevent cheating" mentality prioritized over the "make a fun game" mentality, you're focused on the wrong thing.