• 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.

Archived

This topic is now archived and is closed to further replies.

genovov

Packet Data Question

15 posts in this topic

I am also working on a client/server game. When i did my readup on the subject however, I found that you only need to convert to network byte order and then send [like you say]. But you should be able to use sizeof()s. I mean, a short int on an intel is the same size as a short int on an alpha [isn't it?]. I guess if you send a 64 bit var to a system that can't handle it, then there'll be problems, but I don't see a situation where you'd need to do that. If it's neccessary though, you can code the <64bit client to handle this.

Thus, no, converting to ascii is not needed.

NOTE: this is a combination from what I've read and my own logic/knowledge.

If I am wrong, correct me

~Queasy.

0

Share this post


Link to post
Share on other sites
You certainly should send binary data over ASCII, that's just foolish. You will have to make sure that data sizes match on different platforms. In C, you set up typedefs for specific size data types, then use those throughout your program so that when you port it all you have to do is make sure those typesdefs are the correct size. Also, you have to make sure that your compiler is not automatically padding structures with extra bytes - another source of incompatibilities between platforms.

- Splat

0

Share this post


Link to post
Share on other sites
Simple types such as shorts, ints, longs, etc can have different sizes on different platforms. For instance, last time I programmed a mac (5 years ago!), an int was 16 bits. Under Windows, an int is 32 bits.

What I do is create a header file in which a define my own fixed sized types...

typedef char int8;
typedef short int16;
typedef int int32;
typedef long long int64;

Then if I need to port to another platform I just need to change this header.

The only other thing that really differs between platforms is the byte order. There are some useful functions in winsock2.h (htons, htonl...) for swapping between native and TCP/IP byte ordering. These functions are also in BSD sockets so they will work with Linux. Don't know about other platforms though!

0

Share this post


Link to post
Share on other sites
I was under the impression that 64 bit alphas were only able to address data aligned on 32 bit boundries. I assumed that this would require padding 'byte' and 'short int' vars to 32 bit. I suppose that is not necessarily true. But if data type sizes were always the same, on all systems, why use sizeof() for base data types?

Does anyone know if there is a network byte order function for floats? I haven't seen any mention of such beast.

I was reading some docs on the design of XShipWars, and they use ascii text for their packets, with the claim that it solves porting issues...

But I'd much prefer to go with binary data, as it's more compact, and you can compute the size of a packet based on the data type sizes.

Thanks for the reply : )

0

Share this post


Link to post
Share on other sites
Another quick question for Splat:

I'm aware that most (all?) c/c++ compilers pad structures to 2/4/8 byte boundries, to speed memory access. Do compilers usually provide a way to prevent this from occuring, for specific structures? When I was using DJGPP, there was a #pragma you could use for individual structs, and I believe the gnu compiler has a command-line directive to prevent padding for ALL structures. Is there a similar directive or pragma for individual structs for gnu? What about MS Visual C++?

Obviously, this could greatly simplify my network code, and still prevent sending padding over a socket.

Thanks
-g

[This message has been edited by genovov (edited November 17, 1999).]

0

Share this post


Link to post
Share on other sites
Ye ole #pragma for Visual C++ packing rules:

#pragma pack(push, original)
#pragma pack(1)

...

#pragma pack(pop, original)

- Splat

0

Share this post


Link to post
Share on other sites
I think IEEE floats and doubles are standardized, so platform issues _shouldn't_ exist. Never tried though.

- Splat

0

Share this post


Link to post
Share on other sites
The four biggest guidelines for writing portable data structures:

* Define explicit data types (int8, int16, int32) and avoid implicit types like int.
* Align data to natural boundaries (16 bit types at even addresses) and avoid implicit padding by the compiler (even if you have to add your own padding).
* Pick a byte ordering and stick to it. I prefer big endian, but it's trivial to just define macros that do the right thing by platform and use them everywhere.
* Translate the data once, as it's imported, recv'd, or read and exported, sent, or written. All data structures in memory should be in native format, all data on disk should be in portable format.


0

Share this post


Link to post
Share on other sites
Splat: IEEE IS standard, but you still need to be aware of little/big endian issues. (I.e. an 8-byte IEEE double precision floating point number looks different when stored in little endian compared to big endian...).
0

Share this post


Link to post
Share on other sites
Niels: True, true. Endian differences are always something you have to deal with.

- Splat

0

Share this post


Link to post
Share on other sites
Well, thanks to all who replied. I think I've got all the information I need to proceed with this part of the network coding : )

I've got a new question though. I've read in numerous places, that the UDP/IP protocol offers faster transfer times (smaller headers, and no packet ordering or guarantee of reciept) than TCP/IP. I've read that 'packet' loss can be as high as ~20%. My question is what exactly determines what data will be in a 'packet'. Does every call to write() on a socket create a new packet? I've heard there is an algorithm (forget the name) that is used to buffer TCP/IP data for optimum efficency. Is this algorithm also applied to UDP/IP transfers? I ask because I want to know if I have to deal with cases where I will recieve only the start or the end of a message that I've sent, or if i can insure that each of my networking messages exist in one and only one packet.

-g

0

Share this post


Link to post
Share on other sites
I've been working on a small client/server multiplayer game in linux, with the intent to porting the client to other os's at a later date. Keeping portablity in mind, does anyone have any suggestions on how to send data between the client and the server. I was initially sending binary data, thinking that it would make for smaller packets, but then realized that writing sizeof(foo) bytes on one machine and reading sizeof(foo) bytes on another machine wouldn't work, if their internal representations are different (alphas for instance). Also, am I correct in assuming that endian-ness would also render this method useless, without conversion to network byte order when sending and recieving?

The only other option left seems to be converting all data into ascii text strings, sending it, and then converting the text back into integers/floats ect. Would printf()/scanf() do the trick? Does anyone know how this is done 'in the real world'?

Thanks a bunch

[This message has been edited by genovov (edited November 17, 1999).]

0

Share this post


Link to post
Share on other sites
UDP is simply a packet on the wire, and doesn't perform any sort of reliability or flow control (Nagle's algorithm). UDP packet headers may be simpler, but can't take advantage of TCP header compression.

UDP packets are usually sent with sendto() and recv'd with recvfrom(), so that you can specify the remote address -- since there is no actual connection between the hosts. Each call to sendto() sends a single packet, and each call to recvfrom() reads one in (if available).

UDP is nice if you want fine control over the retry and flow control algorithms (games have different needs than FTP software), but if you aren't network-savvy, then it's easy to ruin your performance instead of improving it.

0

Share this post


Link to post
Share on other sites
I''m still a bit confused . Maybe a quick example will clarify my question.

Two processes are sending packets to each other, with open UDP sockets. Process1 has sent 3 16-byte packets since Process2 last called recvfrom(). Assuming no packets were droped, and that all three have arrived, what will happen when Process2 calls recvfrom again, with a maxlen parameter of 48(3x16)?

Will it read in 16 bytes(1 packet), or 48(all three)?

Thanks,

-genovov
0

Share this post


Link to post
Share on other sites
recvfrom() will only return 1 UDP packet, no matter how many are queued up. It also will truncate the packet if the buffer you pass is too small -- you lose the rest of the packet.

recv() will try to fill the buffer you pass it with TCP data, regardless of how it was sent (1 large packet or 50 small ones). It''s a "stream" format, so all the data just runs together, and it''s up to you to accumulate and break it into messages.
0

Share this post


Link to post
Share on other sites