Hey, I just wanted to throw in my two cents for a new addition that could be made to Calcnet2.2 for a release of DCS8 or something: application tags. Basically, along with the 5-byte calculator tags derived from the serial number, frames also have a 5-byte application tag derived from a hash or 5-byte checksum of the program code. When broadcast frames are sent, instead of being sent to everyone on the network, they are only sent to those running the same program, as determined by the hash. This would allow mulitple programs to run on the same network.
Already in my plans. Smile The main bottleneck in my implementation of this is that I need to make it backwards-compatible in some way. I sort of have a spare 7 bits in the size word that I could use to indicate that the frame has a special field for the program fingerprint, but that wouldn't make Cn2.2 clients ignore that frame or discard it. I need to think further about a proper implementation plan.
That would be cool! Would it then be possible that you don't have to type in a hub via GCN, as each program finds itself?
Sorunome wrote:
That would be cool! Would it then be possible that you don't have to type in a hub via GCN, as each program finds itself?
That would be the idea. The only problem from a hub-management standpoint that I see there would be that all Obliterate players, for example, would end up on the same hub.
Maybe you could update the game with something like as in Star wars empire at war (dunno if you know it, so i explain now), that you can create a game and say how many players, and say how many As and all users can brows all available games and if a game is full the one who hosted can press start and then it starts with these persons. Hope you get what I mean Smile
Sorunome, you mean a server browser. This is actually a very good idea. It's how most modern multiplayer games (except those that rely on direct matchmaking) give you multiplayer dynamics as opposed to the older methods (direct IP, ect) that CN2.2 currently rely on. Really this is dependant on the application programmer, not the protocol, and is already possible. Kerm could very easily write "Obliterate 2" today and include a game browser, which would allow players to host their own game or join an existing one, and by simply polling the network for existin games it would obviate the necessity of a host server to simply host a server listing. Pre-game chat in the game browser might, though.
KermMartian wrote:
Already in my plans. Smile The main bottleneck in my implementation of this is that I need to make it backwards-compatible in some way. I sort of have a spare 7 bits in the size word that I could use to indicate that the frame has a special field for the program fingerprint, but that wouldn't make Cn2.2 clients ignore that frame or discard it. I need to think further about a proper implementation plan.

The spare 7 bits in the size word might help, although I really think that this feature would require a compatibility break - maybe attach this feature to CalcNet 3 instead of 2.2.

KermMartian wrote:

Sorunome wrote:
That would be cool! Would it then be possible that you don't have to type in a hub via GCN, as each program finds itself?

That would be the idea. The only problem from a hub-management standpoint that I see there would be that all Obliterate players, for example, would end up on the same hub.

I was actually thinking more along the lines of still having mulitple hubs, BUT two different programs could easily use the same hub (e.g. these four people can play Obliterate, those four people can use Chat, and both users would not recieve interference from each other's frames).
Well yeah, it would be CALCnet 3. Smile But ideally I'd like CALCnet 3 to still be able to carry CALCnet 2.2 traffic without totally dying; sadly, it sounds like that might be impossible. Bleh.
KermMartian wrote:
Well yeah, it would be CALCnet 3. Smile But ideally I'd like CALCnet 3 to still be able to carry CALCnet 2.2 traffic without totally dying; sadly, it sounds like that might be impossible. Bleh.

Well, on the bright side, if you break compatibility, you can do other compatibility-breaking improvements as well, such as allowing more bytes in frames or increasing transmission speed by sending more bytes at once or compressing frames.
Another way you could add a visage of backwards compatibilty is to allow the new version of DCS (aka "DCS8") to use both somewhat seamlessly:
1. DCS keeps a boolean switch in memory indicating whether to use Cn2.2 or Cn3. DCS8 programs can read this switch. When the CalcNet vectors are called, DCS will redirect the program to the right routines.
2. DCS8 headers contain a special byte that indicates whether or not the program depends on Cn3 for its linking features.
3. When DCS opens a program, it detects whether or not the program was created for DCS7 or DCS8. If it is a DCS7 program, DCS8 will lock into Cn2.2 mode for the duration of the program.
4. Otherwise, DCS will assume Cn3, and all of the unconscious features of Cn3 will be used (e.g. app hash sending). If the "I need Cn3" bit is set in the header, all of the conscious features will be available as well (e.g. larger frames).
5. However, if any Cn2.2 frame is detected on the network by the Cn3 calculator, it will react accordingly:
a. If the program can use Cn2.2, DCS will switch to Cn2.2 mode. The program will be notified that this occurred (e.g. to tell the user), and the calc will not switch back to Cn3 until Calcnet is turned off.
b. If the program depends on Cn3, the calc will "shun" the Cn2.2 frame by jamming the network so that the errant calc sending Cn2.2 will stop sending.
Bleh, I've had this topic open for a while intending to respond to it. My writers' block with it is that I don't see a whole lot to criticize about what you wrote, since some of it mirrors the thinking I had already been doing and the rest is very reasonable and logical.As always, the primary difficulty in all this is that Doors CS contains very little free space for all that communication logic, and even though CALCnet 3 would be something to add to Doors CS 8 rather than Doors CS 7.2 or 7.3, I hope not to go over three pages due to how much people like to whine and complain about Doors CS's size.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement