Anyone have much experience with sockets?

I need packets to act as a transceiver between the client & host through a server, but have yet to do anything TCP or UDP (or really understand the difference) as of right now.

What I'm basically asking is, for a simple packet transfer between a client & host and/or many clients to one host. packets will be small, however will be frequent. Will I require some state-of-the-art co-located rack server or will I just need a bog standard EU rack server based in Europe somewhere and it will suffice worldwide?

Latency isn't that much of a problem. If there's a one->5 second delay, it doesn't matter. If it starts taking the piss, then I'd rather upgrade.

And also, if you know any good providers that would help too.

Not looking to pay more than £150-200 pcm.

 

I don't really understand a lot of what you are saying but I will try to help with what I know lol. So TCP and UDP are the two main protocols underlying the application layer in the internet stack. I guess it really depends what you want to achieve. If reliable data transfer is a must, TCP is the way to go I think. TCP ensures that all data gets there whereas UDP does not. However keep in mind there would be consequences using TCP (extra round trip times because of the necessary handshaking that is required to establish a connection in the first place). UDP is good if you aren't so worried about a bit of lost data (like video streaming for example). It is possible to have reliable data transfer with UDP too but I am not too sure about how that works. If I had to guess I would say you would want to be using the TCP protocol. A few examples of what TCP is used in is email applications, requesting a web page through HTTP protocol. Keep in mind TCP is also slower because it has packet congestion control. I don't think UDP has this which is why there typically isn't reliable data transfer (packets can get lost or overflow the stack in queue if too many packets are being sent). I think... not really an expert here lol.

TLDR the UDP protocol is definitely the more simpler protocol however usually it is the wrong choice in most cases (since majority of applications would want reliable data transfer). Roughly what does your application need to do?

And I would imagine you would want your host server as close to your potential clients as possible to cut down on the routers and transmission links the packets would have to traverse. Too many depending on the rate at which each link is pushing bits could cause lag in a node. You say the packets are really small so this probably wouldn't be a problem.

Also another thing I forgot to mention is that I don't think UDP offers data encryption... TCP does I think. UDP is basically just a really no-frills protocol lol. It has its uses though.

 

Thanks a lot for the explanation. It looks like TCP will be the only option for what I require.

Basically, it's turn based. However, the information is not distributed from the server, the server is just used to transfer to data. So the host, would be one of the players in the game. They'd (clients) send requests and messages from the host would be returned.

The game-play is client-sided then once they basically hit the OK button, they send their data to the host (if they aren't the host) and the message is received from the host and distributed to all the other clients. So, as I was saying. a few seconds delay isn't really a big deal, it will not be noticeable unless you're in the same room. (and if they have a problem with that, there's a local network using multipeer )

However, I'm expecting traffic to be quite high. Which means, one server possibly serving a few thousand people at once, with small data packets. I don't want to be left with a shutdown server and people going elsewhere.

 

Contact me on Skype if you want a free textbook (electronic version PDF). It is the one we used in my networking class. It is an intro to networking book so it might help you with some stuff.

 

Excellent mate, I'll give you a shout when I'm next on skype. Cheers buddy.