   TCP and UDP together?
  Would that work? Is that bad idea and if so for what reasons?Been thinking that while TCP is slower it does give safety easily. Could one use UDP for speed critical messages where few packets lost here and there doesn't matter with TCP for less speed critical messages alongside(chat messages comes to mind for example. They aren't THAT critical to arrive afterall)? Or would the use of TCP slow down UDP alongside so that any speed gained would be lost when TCP is used?Of course another solution would be to implement packet security in UDP for messages that needs it but that's pretty complex thing to do. If TCP could be used alongside without it interfering UDP that would be useful already.   
  TCP gives piece of mind while UDP will keep you wondering (and may make debugging difficult). How badly does you application need UDP over TCP? The difference between the two is not as huge as you may think. Bit torrent is an application that uses UDP to transfer data and it does data validation on large chunks of data. If a large chunk is damaged, it asks for it again (which can be quite costly, considering the default chunks are in the range of Megabytes). Take a look at your bit torrent application and see how many times it needs to re-download chunks. That's UDP for ya. But it doesn't happen as much as you think and I would say it has a fairly good reliability rate (95%).I would personally stick to TCP all the time and in order to speed up transmission rates, keep the information sent to a minimum (or, if you can, compress it).EDIT: Take a look at this comparative analysis.   ;  Make sure you read the Forum FAQ. Also research reliable UDP. It's a method of using UDP to do what TCP does. So you can have reliable in order packets. You can even have some in order and some out of order and some reliable and other unreliable. Also look into raknet if you don't want to program this.This might not be necessary at all though. TCP is perfectly fine most of the time. What are you making? FPS, RTS, turn-based game?   ;Quote:Original post by SirisianThis might not be necessary at all though. TCP is perfectly fine most of the time. What are you making? FPS, RTS, turn-based game?True it's possible it's enough even if it would be used for large scale action. Though since this is more of a technical exercise it won't likely be used in large enough scale that TCP would truly be issue(especially since most of the testing will be done within same house anyway. Not much testers. Especially ones who could be online at same time). However since I'm trying to make it so that it could in theory handle multiple persons I would like to get networking fast enough. Need to do some sort of stress testing one of these days to see how much data it can accept. Guess I could create say 100/200/300/400/500/600/700/800 creatures to same zone(that's VERY cramped zone) and move them around and see what the lag is with each when they move around randomly. Guess that ought to give me better idea how much stuff I can have in one zone(each zone being 32x32 tiles big with each tile being 2x2 big in openGL terms with one character being around 1.8 big in openGL terms) interacting before things get laggy. Can't maybe test out with 300 client but 300 NPC creature should be doable. Hmm...Could mayhap open up second program which just opens 300 ports to simulate 300 clients to whom server sends messages as well. Sounds like a plan.As for what type closest equilavent would be MMORPG though I don't expect to get anywhere near large enough to be called MMORPG. What it so far allows is to login to server and move around in 3d-world. Screenshot here. And yeah graphics aren't that good. I have never claimed to be good with 3d modelling ;-)However it does need to get location co-ordinates at fast enough that it won't lag. I'm trying to figure out some sort of prediction feature to client though how to prevent warping around annoyingly is another thing.(oh and raknet isn't that good idea since I specifically am *trying* to learn it low-level. SDL_net is as high as I'm willing to go. Since this is technical exercise rather than trying to get complete game done, which I would never get done in time and to which I would have no 3d models or textures to support anyway, I might just as well do it the hard way on network and try to code solution myself. Gives out better understanding of how things work low-level than with high-level. And as said wether it takes long time or not is irrelevant since I don't have resources to do complete game anyway. Even if I would get code done and ready I would be stuck with 3d-models and textures :D)   ;  Plenty of MMORPGs actually use TCP. Tibia is a good example (http://www.tibia.com) -- it relies completely on TCP and hosts a maximum of about 800 players per server (plus hundreds of monsters and NPCs). World of Warcraft, too, uses TCP... Or at least it did years back.There are a couple of things that I would take into consideration before using TCP for an MMOish game, though:- You need to open one socket per connection. Some OSes limit the number of open sockets, and it will also introduce additional overhead as you have to poll each socket for new data.- TCP typically defaults to enabling something called Nagle's algorithm (see forum FAQ) which will cause your packets to be delayed by approximately 200ms unless it is disabled.- When Nagle's algorithm is disabled, every message (or part of a message) has to be sent in a TCP packet of its own. The TCP header is large, so expect it to use a lot of bandwidth.The bottom line is that if you need the speed, control and bandwidth I'd recommend using a UDP based protocol that allows you to send both reliable/ordered and unreliable/unordered packets. If it's just a test project, as your post suggests, then you will be fine with TCP. ;Quote:Original post by WindryderPlenty of MMORPGs actually use TCP. Tibia is a good example (http://www.tibia.com) -- it relies completely on TCP and hosts a maximum of about 800 players per server (plus hundreds of monsters and NPCs). World of Warcraft, too, uses TCP... Or at least it did years back.Still does. Or atleast their support page refers to TCP ports when it comes to firewall issues. Boy did my jaw drop on that :D Ultima Online also aparantly uses it(and since Ultima Online is basic inspiration to my program bodes well). Still I expect them to do it in pretty smart way.Anyway as said this isn't going to be used in such a large scale anyway. Whole thing started out of curiosity to how they are roughly done inside. Since I positively SUCK at trying to comprehend other people's code from scratch it's in essence easier for me to satisfy my curiosity by doing rough version myself(also teaches me tons of programming in general and also turns out it just might be final project for school for me).Quote:- You need to open one socket per connection. Some OSes limit the number of open sockets, and it will also introduce additional overhead as you have to poll each socket for new data.Hum. Well I suppose that's dealable. a) I would expect that atleast ONE linux distribution doesn't limit it(and since I work atm on linux having server on such distribution wouldn't be issue anyway) and b) if this would get large scale enough that there would be such a client amount I would do the world in multi-server style. In essence my zone splitting idea extrapolated to bigger scale. Rather than one server doing everything I would have one server to act as gatekeeper/updater. Clients login here first and get neccessary updates. Then based on where their character is they are redirected to new server. World itself is separated to multiple server sectors each ran over by server machine. Each server has the world then split into multiple smaller zones which are what I have now to limit number of messages(basicly messages only get directed to players within specified zone distance. ATM zone source of message is in + neighbour zones). This way as players would likely be spreading across the world rather than being in same place all the time each server would have lighter load. Would be quite a work to do(especially the part when it comes to borders of server worlds where you need to interlap a bit) but in theory that's how I would handle(and as for costs of multiple servers if I would have enough users for the socket count becoming issue I would assume I would have money for more than 1 server anyway). Maybe I'm totally off with this idea(haven't tested it obviously. a) that's lots and lots of new code to be done and not easy code either + b) that would require server farm to test in...Which I obviously don't have when I have on my own only one computer! This would in essence require 3+ computers minimum unless one acts as gatekeeper/reqular server at same time) but in general sounds like it should work. This also helps burden of calculating action for all the NPC characters since each server would have lot less of them to worry about.Yeah I'm crazy. I plan these things eventhough it has no practical purpose but as said I got curious how MMORPG's are done inside so I'm trying my best to figure out as much of them as possible.Quote:- When Nagle's algorithm is disabled, every message (or part of a message) has to be sent in a TCP packet of its own. The TCP header is large, so expect it to use a lot of bandwidth.Good thing then I wrap all the messages from one processing loop to one packet which I send in one go. Exception being if there comes so many messages that it exceeds specified size.Quote:The bottom line is that if you need the speed, control and bandwidth I'd recommend using a UDP based protocol that allows you to send both reliable/ordered and unreliable/unordered packets. If it's just a test project, as your post suggests, then you will be fine with TCP.That would be best solution but that has the part of being harder to implement.And yeah test project more or less. I'm not stupid enough to think I could create new WoW on my own ;-)   ;  I'm doing a MMO, and we're using TCP and UDP too.We're gonna use UDP for ordinnary messages between the client and a proxy that communicates with the game servers. Between the proxy and the game servers we're gonna use TCP over a dedicated (or gigabit) network.Also, when it comes to concerns about buying things within the game, using real money, we want to use a TCP connection.So, i wanted opinions from you about this architeture, the client communicating with a proxy, via UDP, and the former with the game server itself, via TCP.Thanx in advance,Best regards!   ;  Check out the network section on this website:http://gafferongames.com/Really good stuff.   ;  matt, what exactly do you want the proxy server to do?  If the clients already can talk directly to the game serer, why wouldnt they just send the messages directly to it?Usually the problem about buying items and stuff is not that important net packets gets dropped, but flawed logic, making database and in game memory come out of sync, allowing for dupes or fake sells.   ;Quote:Need to do some sort of stress testing one of these days to see how much data it can accept. Guess I could create say 100/200/300/400/500/600/700/800 creatures to same zone(that's VERY cramped zone) and move them around and see what the lag is with each when they move around randomly.This is not protocol problem, but it will be determine completely by the simulation model. Having tens of thousands of somethings might not be a problem if they are inactive. But updating only 5 somethings can be problematic if update rate is high and involves lots of shared data.Quote: Guess that ought to give me better idea how much stuff I can have in one zone(each zone being 32x32 tiles big with each tile being 2x2 big in openGL terms with one character being around 1.8 big in openGL terms) interacting before things get laggy. Can't maybe test out with 300 client but 300 NPC creature should be doable. Hmm...Could mayhap open up second program which just opens 300 ports to simulate 300 clients to whom server sends messages as well. Sounds like a plan.No matter how data is sent over wire, application will have a single, abstract API, which will have send() of sorts. How do you intend to call that, with what data?Implementations of send() will then be fairly similar, since regardless of TCP or UDP, there will be some form of connection. In UDP, you'll roll your own, TCP comes with its own definition. Simply sending raw UDP is probably not feasible.Quote:Also, when it comes to concerns about buying things within the game, using real money, we want to use a TCP connection.Which doesn't solve anything really. Both, UDP and TCP offer reliable transport, but they give no guarantees about ACID property of actual logic.The "using real money" and relying on TCP to ensure completion is scary, to put it mildly.UDP: You mail your money to the bankTCP: You hire FedEx to deliver your money to bankReliable UDP: You hitchhike to bank so you can deliver the moneyBut neither of those has anything to do with money being safely delivered. One can always get mugged, only the methods by which it happens vary.   