Sounds good. A simple tech demo of networked interactions is something that is pretty simple and good to start with. However, you need to make a chat program first as that is more suitable for your initial task. Writing a non network game can be challenging enough if you are not a game programmer and have a lot of experience. Trying to write a networked game when you don't have network experience either is all the more harder!
[/quote]
I am not sure writing a chat program is a suitable place for me to start. I did not to long ago create a client and server for sharing libraries. The server would allow multiple clients to connect and download files off the server. I am very familiar as well with networking. Last year I passed my CCNA course. I therefore know a great deal of how network protocol works as well as there structure.
Personally what I am building I would hardly count as a game. The graphics and mechanics for this "game" is the least thing I am concerned about. Its almost unimportant to an extent. Being able to build my own protocol and with flow control and etc is what's more important. My university course is called Computer systems and Networks. The only thing I am required to demonstrate for my final year project is some form of distributed system. So a chat program would do the trick, however I have just spent the last 7/8 months building the framework for a game engine. I don't really want to stop doing that just to take on another project. I still am open to that sugestion though.
I completely understand how the serialization works now after playing around quite a bit with hplus code (I could not get your posted code to work, I am sure I am missing something there).
[color="#1C2837"]Implement your own network protocol (assuming you already have a network library/framework to use). This will allow you to take the payload of your messages (what the visit pattern gives you as output) and attach what type of data it is (usually designated by an 'opcode') as well as the size. Remember TCP is a stream, so you must send the size of the data that is following. Once you have your own protocol, you can now just communicate between endpoints and worry about the actual network logic. If you are using UDP, then everything stays the same, except your protocol is slightly different. However, that is a different topic, so in context of this thread, everything is the same in regards to the visit pattern. [/quote]
[color="#1C2837"]For the game I plan on using UDP, however if I was to go down the path of a chat program I would of course use TCP for the reliability sake. I am a bit unclear by what you mean when you say "opcode"? I have used hplus code to serialize all my data but can't figure out how to send it across a local network. I can send the data but it shows up on the other end as being the same size/capacity, it just do not get the data.
[color="#1C2837"]I understand how the serialization works but after using hplus code it seems to have all the bytes in a buffer as a char. When I go to deserialize this code how can you determine what the code was in its original state? eg an integer, char, string and etc....
[color="#1C2837"]I feel like this serialization stuff is a just a bit of a roadblock right now and that if I can get around it I would be set. I know thats not how these things always work. I thought about maybe using the boost library for this but heard it has a lot of overhead. What do you guys think about the boost library?
[color="#1C2837"]I know you probably have explained this all to me several times and i thank you for your patience. I am doing my best to achieve this myself.
[color="#1C2837"]Many thanks
[color="#1C2837"]agisler
[color="#1C2837"]p.s - I am using visual studio 2010 for my IDE.
Packet data types
Author
The world is changing. I've long thought for example, that Microsoft is at a disadvantage to Google. Google wasn't afraid of the cloud; they embraced it. Microsoft goes around trying to get countries to crack down on software theft. I think that's a tough proposition and they are huge. I don't have to worry about things like that with this model.
Here we go again.
http://online.wsj.co...p_sections_tech
The article is helpful, but would be even better if they would call a spade a spade. Let's drop the use of the word pirate. It is stealing. The Chinese lead the world in theft. Thank G-d for the cloud.
I don't understand why you would want to be able to resend a packet when your running a real time game. Am I missing something here?
After looking over this discussion, I'd like to answer in a slightly different way:
If I send a "position update" message, and it gets dropped, then that doesn't matter so much, because I will send another, newer, position update message in a few dozen milliseconds anyway.
However, if I send a "chat text" message, and it gets dropped, then I really do want to have it re-tried, because I want everyone to be able to read what I'm trying to say.
Similarly, in games, there are many kinds of data (evolving state) that really are "freshness over all," and other kinds of data (edge-triggers, say) that need to be reliably delivered. For example "so-and-so won the game and it's now over" is a message you really don't want some clients to miss :-)
Game networking has some unique challenges, because latency is really important, and the kinds of data it needs to deal with is diverse. Any game networking protocol will have to solve a bunch of appication-specific problems. By contrast, most other network protocols (HTTP, RPC, IPTV, VoIP, etc) do not have all of these problems at the same time, and thus are generally simpler in design.
However, the corollary here is: If you don't understand what happens on the inside of games and simulations already, you really aren't in a good position to come up with a robust game networking protocol that solves the actual challenges involved. And, because the challenges and trade-offs are different for different game genres, you generally focus on one particular genre (FPS, MMORPG, RTS, turn-based, ...) rather than a Grand Unified Theory of Game Networking.
There exists a lot of research on game-style networking already. However, most of the published research is for protocols like DIS (which is robust, but not very efficient) or HLA (which is neither robust nor efficient). Meanwhile, the state of the art is pushed forward by game studios, who don't really publish peer reviewed papers, so you'll have to trawl the Internet for references. "Quake III Networking," "Source Engine Networking" and "Age of Empires Lock-step Networking" are good things to search for (check the FAQ, for example). However, if this is a research project, a literature overview probably also need to talk about DIS and HLA to start with, and explain what's wrong with those approaches.
Author
Thank you hplus. That all makes perfect sense.
I have been working on the serialization and have that completely understood now. The only thing i have been struggling with is how to send the data once it has been serialized?
Many thanks
I have been working on the serialization and have that completely understood now. The only thing i have been struggling with is how to send the data once it has been serialized?
Many thanks
I have been working on the serialization and have that completely understood now. The only thing i have been struggling with is how to send the data once it has been serialized?
You send data using send() (for TCP sockets) or sendto() (for UDP sockets).
You typically frame the data into some kind of wrapping header. For TCP, this will include the size and type of each message, so that it can be decoded from the "stream" of bytes you get on the other end.
For UDP, this will typically include many messages in the same datagram packet, with some kind of header that contains a datagram sequence number, acknowledgement for previously received datagrams, and timing information.
If you want to build reliability vs non-reliability into your send semantics, you need to do it on top of UDP. Look for example at Enet for an existing, open source implementation.
Author
[color="#1C2837"]For UDP, this will typically include many messages in the same datagram packet, with some kind of header that contains a datagram sequence number, acknowledgement for previously received datagrams, and timing information.
[color="#1C2837"]If you want to build reliability vs non-reliability into your send semantics, you need to do it on top of UDP. Look for example at Enet for an existing, open source implementation.
[color="#1c2837"][/quote]
[color="#1c2837"]I was planning on building all this on top of the UDP within the datagram. For all purposes right now i can't get the data sent and received so i can begin this work. I have a very good understanding of TCP/UDP so that part should not be hard for me to accomplish. I just can't get the data to send in serialized form. If it is just a string of text than that works perfectly fine.
int sent_bytes = sendto(handle, (char*)&str.buf, sizeof(str.buf), 0, (sockaddr*)&dest, sizeof(dest) );
if(sent_bytes!=sizeof(str.buf))
{
CLogger::Write("packet was not sent");
}
According to my checks the data is being sent but i am not receiving data when i send data out on my loopback address.
CInStream newstr;
typedef int socklen_t;
socklen_t fromLength=sizeof(local);
int recieved_bytes=recvfrom(handle,(char*)&newstr.buf,sizeof(newstr.buf),0,(sockaddr*)&local,&fromLength);
if(recieved_bytes<0)
{
CLogger::Write("data not sent");
return 0;
}
I think i am going to use Enet for simplicity purposes. I just would like to know where i am going wrong here.
Many thanks
What does CInStream look like, and what does the type of "str" in the first example look like? Are you taking the sizeof() POD, or are there pointers or complex types inside them?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
