🔒 Locked

Building a Network Messaging API

Started by gimp Jul 25, 2006 at 1:55 PM 4 replies 1.8k views

Original Post

Jul 25, 2006 at 1:55 PM

I'm building my messaging infrastructure. I want to post messages to the server, have it 'do something' then respond with an ack or data that might be relevant. I plan to send a message over the network, wait for a response then when I get it back be able to relate the response to the original request. The original requestor class is then called back in order to get the data. This seems to be awfully close to what I would expect to be a design pattern. Does one exist or is there a batter way to do this? Second minor question, should I use a std::list to store the Requestor callbacks and use the iterator in the network request, so that when I get the response I can relate it back to the original request(or)? I'm pretty sure I can do delete's from within a list and iterators remain valid unlike a vector. Thoughts and comments are welcome as once I implement this I think it'll be pretty embedded and unlikely to change going forwards... Thanks Guys...

kuphryn

Jul 25, 2006 at 2:30 PM

stl map is one better solution

Kuphryn

gimp

Jul 26, 2006 at 5:05 AM

I thought of that. Using a map however requires me to manage the unique index myself. If I use and iterator pointing at a container the iterator is unique(4 bytes) and points at something that wont be invalid, when neighbours become deleted\inserted.

Any takers? Any thoughts on the general design?

peous

Jul 26, 2006 at 5:17 AM

1 adcice: use enet for lower communication code. don't write it yourself execept if it's your choice to write buggy code for months and never have time to use it in a game. http://enet.bespin.org/
enet is C code, you'll be able to make your "clean" C++ design over it

gimp

Aug 2, 2006 at 1:41 AM

Thanks for the answers guys. On first inspection I found the answers sort of off the topic I was asking for which was more around message routing \ handling. I'm sort of half inventing my own RPC type of system.

On looking over the last two reply's however I found that the Enet option is kind of appealing. Initially I discarded this answer based on the fact that this is UDP. They however coded a reliability layer on top of TCP that handles streams.

The reason streams are interesting is that for a message based architecture each request and response, or 'transaction' under Enet is handled in what they call channels. Each channel controls a steam of data back and forth of course all this is, is probably an int buried in the packet to represent the channel number.

I has a look at ASIO and could not for the life of me work out what it was all about. It didnt look like a generic networking library, it didnt look like a network ostream... I don;t know what it is. I'm sure it's cool, but for my project I just HAVE to know whats going on in order to use it.

Many thanks to all!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.