Questions about multiplaying structure and implementations

Hello! I am a newbie to multiplaying game programming.
I am currently working on a 3D Multiplaying Internet Game. The 3D part is working fine. I am planning to communicate using TCP with threads. Sending struct to the others in order to let the game status up to date.

However, I am getting trouble in threads.

Actually, I have got two plans. The first one, one server with three clients. clients send the data to server and server update all the information and broadcasts to the clients. Then, the clients has only three threads. One for their i/o and two for their tcp sockets send/rec operations. However, server might need to have 7 threads. Six for communications and one for self i/o.

The second plan is all peer. Each player broadcasting their new inputs to the others. So, in order to collect and boardcast at the same time, two threads for send and receive for each pair of connection. And, finally, 7 threads needed, as one for self i/o, 6 for 3 others players send/receive connection.

I want to implement the second plan. Am my algorithm alright? I dont have such experiences in implement that. Would it be feasible?

Besides, what else have to be taken care in implementing this kind of structure? I am going to include an unsigned long int variable as a synchronization tool in each struct sent. Would it be too heavy in work load?

In opengl, the redering per second is about 150-180 frames. Could it be possible that the socket could send 150-180 data struct per second?? My data struct is only about 32bytes each.

I have been seraching through the internet. However, the information available is not much. The deadline is coming. Please help!

I would go with the first plan, since it follows the KISS philosophy.

As for the ability to send all those packets you should do the math.

So 32 bytes = 256 bits with 180 sent a second you would have 46080 or 46k bits transmitted a second. But that’s excluding the overhead of TCP.
So it might work, it depends on the connection.

I would definitely prefer the first approach. Sending data to a central from which to be processed and distributed is much easier on bandwidth and systems complexity.

About sending updated: traditionally you'll only send updates to the clients. So if you have a moving player you only send an update when the player changes his speed or direction. This way the client can do the predictable changes on it own. You'll want to send a general update from time to time to ensure synchronization...