I'm creating a client/server winsock FPS arena type game and have been debating on the most efficient way to send all of the data to and from the client. There is a lot of information that needs to be kept up with such as player positions, rather or not someone is alive, etc. Should i just put everything in a large structure and send it? Is there a better way? Any advice would be appreciated. In the past I have sent the data inside of a structure, but this game requires me to send a lot more information at a time. I just want to do my best to send it as efficient as I can to prevent lag.

The FAQ talks a lot about this. You can play with how often you send the data, as well as how you encode the data -- for example, you can encode a float in the range -1000 ... 1000 with a precision of 1/64 as a short (half size) divided by 64. You can also send data at a slow rate -- say, 10 times a second -- and forward extrapolate (or delay) display of entities.
Another approach is to send only input -- direction and movement keys -- and simulate forward; send a "baseline" snapshot once every five seconds or so to "fix" if something goes out of sync.

could someone explain the concept of delta compression? From what I understand by doing some research on quake3's network architecture it's basically the difference between two different packets. So one packet is sent normally, and then the next time the differences in the two packets are sent? I'm not sure if I have the general idea or I'm way off. In the quake 3 source they implement delta compression to a large structure that has to be sent back and forth from the client and server. The structure basically holds a vector for the player pos and integers that define the weapon the player has etc. This is basically what I'm trying to accomplish I just don't have the full grasp on it yet.

It's more complex than that.

First, split the state you want to send into different pieces: position, movement, orientation, weapon state, hit points, ...

Second, number each packet you send, and send back an acknowledgement for the latest packet number you've received.

Third, keep the last N packets around after you send them. N should cover your expected range of latency -- 1 to 2 seconds, say.

Fourth, when you update state, you compare the state you want to send with the state you sent in the latest acknowledged packet. Send only the state that is different between what you want to send, and what was in that packet. Send a reference to that packet, and a bit mask of what pieces of state you will include in the new packet, plus that state.

Now, on the receiving side, it knows how to generate the state that you sent -- look back to the state in the packet it references, copy that, then overlay whatever the other state is that's included in the new packet. Send back an acknowledgement that you received this new packet.

Whenever you get a new packet referencing a "later" packet than what you've previously used, you know you can discard any saved state for earlier packets, because those will no longer be used, as the other end now has a later copy to work off of.