How much data do you need per unit? X and Y and Z positions and rotations? At 16 bit each, that'd be 12 bytes per unit. 100 units is 1,200 bytes, or less than a kb. 30 FPS would need < 36 Kb/s, which I guess is over the limits of most people's upload speed.
Have you thought of sending only a part of the scene? For each frame you could send the position and orientation type data of perhaps a quarter of the objects. The client can move these objects to absolute positions while moving the other objects based on it's own calculations.
eg. For 30 tanks, own frame 1 the client computer receives exact data on tanks 1-10 and places them accordingly, and positions Tanks 11-30 based on position+movements. Frame 2 updates the exact positions of tanks 11-20 while tanks 1-10 and 21-30 are calculated client side. Frame 3 updates tanks 21-30 based on the servers processing. And frame 4 cycles back to tanks 1-10.
Segmenting your updates this way would keep network traffic down to manageable amounts and keep the clients close to the servers output with no worse than a few frames variation which shouldn't be noticeable.
Have you thought of sending only a part of the scene? For each frame you could send the position and orientation type data of perhaps a quarter of the objects. The client can move these objects to absolute positions while moving the other objects based on it's own calculations.
eg. For 30 tanks, own frame 1 the client computer receives exact data on tanks 1-10 and places them accordingly, and positions Tanks 11-30 based on position+movements. Frame 2 updates the exact positions of tanks 11-20 while tanks 1-10 and 21-30 are calculated client side. Frame 3 updates tanks 21-30 based on the servers processing. And frame 4 cycles back to tanks 1-10.
Segmenting your updates this way would keep network traffic down to manageable amounts and keep the clients close to the servers output with no worse than a few frames variation which shouldn't be noticeable.