That is most of what I was trying to say. It was morning so you have to read between my lines. :-)

You are right about the slow start. That can''t be turned off, but causes little problems on a good connection. The sliding window can be adjusted to allow more packets in flight. I dont'' know the exact way, but when jrlogic69 and I were developing VNL, he was able to up the in-flight packet cound. That basically disables it.

And just so you all understand, I''m not saying you should use TCP for your game. I''m just saying that you should not rely on UDP alone. It is NOT better in every case, and will fail you at some point. It is better, as it is in everything, to have multiple chioces.

i would not call linux 2.0+ running on a 386 or higher particular "new" firewall/NAT nor expensive

while true some devices are crap, they are few enough to not impact your suscribtion rate too much (i believe anyway). you think it matters, release a test app. you will get the highest compatiblity using TCP, thats given and there is no arguing that. upto you to decide if you want that extra compatibility.

quote:

---

Original post by smanches
I dont'' know the exact way, but when jrlogic69 and I were developing VNL, he was able to up the in-flight packet cound.

---

Well, now I know who your buddy in Texas is... That is the one library we use that does have TCP. I added reliable UDP to it, under some pretty tight restrictions. It wasn''t fun, and I daresay the result isn''t at all pretty

fingh, did you use a positive or negative ack structure? Did you implement ordering as well? I''m in the middle of our network library doing the reliable UDP service right now. It would be interesting to hear other ideas.

This particular go, I just integrated an existing reliable UDP layer into the library. Because a couple of projects were already using the library in production, we (we = my boss) felt that the existing interface shouldn''t change. This led to some very ugly code on my part, and if I could do it differently, I would, even to the point of drastically changing the "live" api. I''ve since moved on to other projects...

I''ve tried a lot of different stuff with UDP. I''ve tried what you call positive and negative ack structures, even in the same library. The way that''s worked best for me is to resend unacknowledged packets auctomatically rather than having the client request missed packets. Doing it the other way(client explicitly requests missed packets), the latency can get critical - what if the resend request get''s dropped? Using both methods at the same time didn''t work well for me. You start generating a lot of extra traffic if you run into congestion, which just makes it worse. It''s possible to make it work but I didn''t put that much thought into it at the time.

Generally when I develop reliable UDP, I will implement reliable delivery and ordering(optional on a per-packet basis).

Honestly it sounds like smanches is suggesting that you basically build 2 transmission layers, one TCP, one UDP; each with the same functionality. First attempt a UDP transmission mode, no reply, failover to TCP. Sounds simple enough and would add what, 1 second to the login time? If you''re worried about server load, simply build a series of simple connection servers specifically to handle TCP only traffic.

I do agree with him though, there is a lot of difference between the router level transmission of UDP and TCP. Fortunately this is relatively irrelevant because very few backbone connections are very heavily loaded on any but the highest usage days, but it''s not uncommon to find that your cable or dial-up ISPs are overloaded half of the days of the week.

quote:

---

Original post by solinear
Sounds simple enough and would add what, 1 second to the login time?

---

But it''d add what, 2 weeks to the developement time (including testing)? And that''s assuming you''re working full-time on this thing. The point is, will it be worth it? I don''t really believe there are many people out there who can''t play a UDP-only game. Almost all commesial games are UDP only, so why should we spend all that extra time implementing something that we don''t really need?

If I had my way, I''d have all of you shot!

---

codeka.com - Just click it.

quote:

---

But it''d add what, 2 weeks to the developement time (including testing)?

---

OK, agreed. You would have to change your communications module and that might take 2 extra weeks. So you change it in a patch after development is complete, like Origin did. I hope that your communications programmers aren''t overloaded on other projects at that point in time.

quote:

---

OK, agreed. You would have to change your communications module and that might take 2 extra weeks. So you change it in a patch after development is complete, like Origin did. I hope that your communications programmers aren''t overloaded on other projects at that point in time.

---

They will be overloaded trying to defeat the various tools that were created by players on the first day of public beta in order to cheat at your game. They''ll be tweaking monitoring systems. They will wonder why release account keys don''t register properly with existing beta accounts. They''ll be debugging encryption algorithms that insert spaces and other typical delimiters into their string data. They''ll be trying to figure out how to compress some messages but not others (for performance), while not completely hosing the released client software. They''ll be wondering how the company will be able to afford the 10+ expansion servers needed to serve the current player (over)load. They''ll be hunting down hackers that syn flooded them 3 minutes after the servers went live. etc... Most game companies probably don''t have a "team" of dedicated network programmers. Like any other project, someone gets tasked with writing the networking layer. After they "finish" it, they get other tasks, because they still have 95% of the game to be finished. They''ll maintain the source, but there is too much going on to make huge modifications to it that suddenly nullify all of your beta testing and QA cycles by changing the bottom-line core system of a MMOG. Hurray for Origin (no sarcasm). How long after launch did they do this?

Obviously unfunded projects that don''t worry about a budget and a payroll can get away with having someone dedicated to programming just the network stuff. In this case, sure, why not add TCP (other than processing time).

quote:

---

Our team is now working on implementing the network code
(or planning it out at least), and we can''t seem to agree
on which protocol to use.

---

Firt, design the game so that the networking protocol in use is irrelevant to everything outside the network code.

quote:

---

Now, my partener wants to use UDP and TCP for gameplay,
using TCP for urgent packets. But, I would like to use
UDP, but make it secure enough to handle urgent packets,
and constructing it to conform to a "custom protocol".

---

TCP is no more or less secure than UDP.
Using TCP to deliver urgent data is dumb.
By urgent you seem to mean reliable. If the number of clients is small, then using a UDP/TCP combination should be acceptable (so long as you don''t go and create a thread for each and every socket).

quote:

---

My partener argues that using UDP and TCP would be better
because the TCP is handled at the OS level. I, on the
other hand believe that having to handle 2 different
sockets/user would kill cycles.

---

It depends on the number of clients you intend to deal with. If the numbers are relatively small (under 100), then one or two sockets per client should be doable given sufficent RAM. If you want to support *lots* of simutaneous users, you want to use one UDP socket and embed information to distinquish the client in the packets. This minimizes the per socket/client memory overhead on the server - you now have to keep track of additional information yourself, but the socket impl doesn''t need a seperate send & receive buffer for every client.

So long as you use an asyncronous method, and a small number of threads, there shouldn''t be any significant CPU differences.

Also bear in the mind, that supporting hundreds of client would require considerable bandwidth.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]