You can still negotiate compressed streams when you need to, and if that's just not enough, you can negotiate bit-based transfers VERY easily. Read on.
{Edited: Added missing numbers}
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
(Now I think that's all)
Code: Select all
- your counting is incorrect, which perhaps indicates that you have very limited familiarity with working on binary data.)
Sure you can put them back to back to form more complex patterns, but if you did that, you'd be making a char, which is what strings are made out of. A char is:
0000 0000 through 1111 1111
Strings do not incur much overhead. If the overhead of 8-20 bytes is to much for job X, impliment compression to reduce that further, easy enough, or use the other suggestion below.
The advantages out weigh any miniscule speed advantage users on 28.8k modem MIGHT see if they're downloading pr0n at the same time.
Being: If it were done an existing and VERY PROVEN methods (HTTP, TELNET, SMTP, POP3), could all be implimented in the same server over the same port AT the same time, without ANY noticeable speed hit to anybody.
(HTTP being the most important, as it can provide any data about the server anybody wanted to provide. I know of a lot of people who like setting up a website about their game server, and even know some who have gone as far as working their assess off to make callbacks to their game to extract data from it to have it be displayed live on a website (Which can be done in a number of ways, but this way is the easiest, as the code to do it ALREADY EXISTS)
And then if there are things you absolutely MUST argue the speed of a bit based protocol is absolutely necessary or it would all keel over and die, you can use the string based methods to negotiate a bit based stream for what needs it, then switch back - The same way one would negotiate a compressed stream, or even encrypted streams if that's needed - All without ruining compatibility with existing protocols.
My argument is so I can add Vegastrike support to my completely self written multi-protocol HTTP / telnet mmorpg server. (No, I didn't download smaug and hack it up and call it my own. I started from scratch, so I do know what I'm talking about. don't believe me? Look at http://ant.infice.com:5555/index.html )
and try telnet://ant.infice.com:5555 (wow, both work, http and telnet. Not even Apache does that.)
I have been working in the Vegastrike engine, and added a few basic necessitiies to start implimenting this stuff (the command processor).
Not XML, XML-LIKE tags. We would take something like::if using XML, an externally verified parsing engine
<FOO>arguements</FOO>
and translate it to something the command processor recognizes, Exactly like:
FOO arguments
And with this method, it would be VERY easy to processess new tags, without having to add something new to the input routine to decipher a message, as all the tags can be deciphered exactly the same. All that would be needed is for the command "FOO" to be added to the command processor after the function itself to do FOO is created.
Enums are intigers and have absolutely nothing to do network communications and being able to safely parse arbitrary commands between two applications.If the advantage you seek from a readable format is intelligible code for processing such, this is what enums are for.
I don't care how the internals of vegastrike work, this grids, graphs, edges are nonsense pertaining to this particular post. These posts I've made are about how to actually transfer data from a client, to a server, and from a server, to a client. Once the protocol is defined, it can be implimented in anyway, such as a distributed network of server applications running on multiple machines to create a larger universe that's faster and supports more clients, or a single server application with a universe and player connections limited to the resources on that machine.