You are not logged in.
Pages: 1
The most important thing to consider is: are your messages important and need to arrive or can you stand to lose some and not cause any major problems? If they're important, you probably want TCP (ie: connection-based SOCK_STREAM)... If you can stand to lose a few now and then, you might be better off with UDP (ie: connectionless SOCK_DGRAM)... There are other considerations, but I think that's the most fundamental one to think about... There are times where you can effectively rewrite your own TCP reliability handling on top of a UDP socket if you have to when UDP is a better overall fit otherwise, but I wouldn't recommend it if you can avoid it... If you need reliability, your best bet is generally going to be TCP...
I'm not sure what you mean by your question "should I limit the size of the packet"... With TCP, from an app level, you generally don't care about the packets, as you're just working with a data stream... You send as much or as little as you want down the stream, and TCP figures out how to divide it up as packets... Unless by "packets" you meant app-level messages? For those, just pick sizes that make sense for the data you're transfering... You'll probably need to pick an appropriate scheme for sending and receiving the messages; either delimited messages or a fixed-length size header followed by the variable-length data... Because, remember, it's just a data stream, not a packet-based socket like UDP...
Offline
Pages: 1