• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lerno

UDP network layer must-haves?

27 posts in this topic

Submitting fewer messages at a time leaves you with complete messages. Fragmenting data at a lower level (i.e. split up "binary data" agnostically of the message structure) will likely contain partial messages that can only be received by assembling fragments.

 

Insofar, doing this at application level is arguably cleaner and "better".

0

Share this post


Link to post
Share on other sites

If you really care about MTU, google "path MTU discovery" and check the "don't fragment" flag in the IP packet header.

1

Share this post


Link to post
Share on other sites


Submitting fewer messages at a time leaves you with complete messages. Fragmenting data at a lower level (i.e. split up "binary data" agnostically of the message structure) will likely contain partial messages that can only be received by assembling fragments.
Insofar, doing this at application level is arguably cleaner and "better".

 

It does have the drawback that it breaks the abstraction. So now the application has to: 1) estimate packet size - meaning it must know the details of how the serialization works, 2) query the networking layer for maximum packet size and 3) add code fragmenting and defragmenting updates at various places (been there, done that).

 

It also means that any change in the networking layer might suddenly touch a whole lot more code than just the parts directly related to networking.

 

Doesn't sound ideal.

0

Share this post


Link to post
Share on other sites

If you really care about MTU, google "path MTU discovery" and check the "don't fragment" flag in the IP packet header.

But also note that if you have the DF flag set, and your packet is larger than the MTU along the route to the destination... your packet will get dropped. No special effort will be made to route your packet around network segments with MTUs less than what your packet size is. Edited by Washu
0

Share this post


Link to post
Share on other sites

if you have the DF flag set, and your packet is larger than the MTU along the route to the destination... your packet will get dropped.

 
That is the point! You can easily use binary search to find a proper MTU to use for your entire path this way. You only need to stop on some reasonable multiple, say 128 or 64, so a few packets is all you need to get there.

Start with 2048. If it works, double it. If not, halve it. Then binary search until the difference between "works" and "doesn't work" is your search granularity size (such as 128.)
0

Share this post


Link to post
Share on other sites

The one I built had a special file transfer transaction mechanism (the whole 'file' data block defined to not be useabale til it recieved intact other side).     Simplified ACK retransmits by using a bit flag return msg (if any were never recieved) sent after a whole pass on all the packets needed to send the 'file'  (flagged packets only would be resent)  and this repeated if necessary til entire 'file' is intact.  packets got dumped directly into the right place in a preallocated file buffer to eliminate extra block copying.

 

 

It was a while ago, but that one also had callback signals to an Application level that could cause throttling at a high level (where the App could make smarter decisions about how to handle a  data flow slowdown into the server.   This meant of course the packet driver needed some criteria to determine when to start alerting the Application layer.

0

Share this post


Link to post
Share on other sites

 

if you have the DF flag set, and your packet is larger than the MTU along the route to the destination... your packet will get dropped.

 
That is the point! You can easily use binary search to find a proper MTU to use for your entire path this way. You only need to stop on some reasonable multiple, say 128 or 64, so a few packets is all you need to get there.

Start with 2048. If it works, double it. If not, halve it. Then binary search until the difference between "works" and "doesn't work" is your search granularity size (such as 128.)

 

What if the path changes?

0

Share this post


Link to post
Share on other sites

 

What if the path changes?

 

Then you're either using a non-optimal (too small) MTU or it will drop, depending on whether the new route has a higher or lower MTU.

 

I would still go with 1280 for simplicity, or if you really want to do a MTU discovery, do your binary search between 1280 and 1500.

 

The reason being that 1280 is guaranteed by IPv6 (and every router that isn't in a museum is IPv6 capable, so it must have at least that MTU) but on the other hand you are not likely to get more than 1500 as this is what standard ethernet delivers, and there is "always some ethernet" in between you and the other computer. Unless everyone configures their cards and routers for jumbo frames, which probably won't happen.

 

Of course a granularity of 128 is way too coarse for such a small interval, especially since that would only leave the choice between 1280 and 1408. Note that 1280 is what the "start at 2048" binary search would eventually converge to, too (2048fail --->1024work ---> 1536fail ---> 1280work).

0

Share this post


Link to post
Share on other sites
Actually, once you've discovered the MTU, you don't use the DF bit anymore, so if the path changes, you may end up with IP fragmentation, but it will stil hopefully work well enough.

not likely to get more than 1500 as this is what standard ethernet delivers, and there is "always some ethernet" in between you and the other computer


Gigabit Ethernet and up typically supports jumbo frames, for 9,000 bytes per packet. On the other hand, ATM transmission packets are 53 bytes; 48 payload and 5 address. You're not going to avoid physical fragmentation there -- but at least that fragmentation is done on the physical layer, and "invisible" to the IP layer.

For 99.9% of games, I would suggest not worrying about it. If you're using TCP, don't worry -- just make sure you turn on TCP_NODELAY, and make sure you group your outgoing packets into a single send() call per network tick. For UDP games, pack your messages into a single UDP datagram per network tick, and because you don't want traffic to be too large (or the server will have a significant upstream bandwidth problem,) you don't want each UDP packet per player to be bigger than 1280 bytes anyway.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0