CALCnet 2.x Whitepaper Development

[KermMartian]

[christop]

Kerm, did you happen to make that little program you said you would throw together for us?

Hooray for necro-nagging!
_________________
Christopher Williams

[Lionel Debroux]

Oh yeah, forgot about this topic

Several nifty little debugging tools would definitely help making a full port of CALCnet, which would be a major improvement over my one-way implementation which supports only broadcast sends.
For maximum usability of the CALCnet implementation, we have to write the Punix implementation on top of a standalone implementation, provided in a function archive for static linking with user programs.
_________________
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

[KermMartian]

Gar, never did throw it together. It should display the five bytes of the target address of each frame sent, perhaps the size, and the first few bytes of the frame?
_________________

[christop]

Yeah, the sender's address would be helpful too. But don't worry too much about getting this done right away. I don't know about Lionel, but for me this is a low-priority, back-burner type of project.
_________________
Christopher Williams

[Lionel Debroux]

You sent me a program which displayed some of this information (and I used it to confirm that the frames generated by the 89 and 89T are understood by the 83+/84+), but I think that both christop and I are thinking about tools even more detailed than this, if possible

And indeed, it's a rather low-priority project for me as well.
_________________
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

[KermMartian]

Indeed, but we might as well bang out what exactly would be helpful for you guys so that I can thread it into the rest of my work. What more detailed tools are you imagining?
_________________

[Lionel Debroux]

Perhaps some more readable information on why a packet was rejected by the reference implementation (bad checksum, etc.) would be useful ?
christop, any ideas ?
_________________
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

[christop]

How about a Wireshark-like GUI with a list of packets and all fields decoded so it's easy to see exactly what the fields mean.

Actually I can't think of anything else to add to it. To be honest, I haven't thought about it much since I originally didn't have a TI-83+ to play with, but I do now so I can try to test it out. Unfortunately, I don't know where I placed my TI-86 now.... :/

Maybe I'll try my hand at a version for Punix. Since it doesn't have any infrastructure for networking yet, I'll just hack it in as a character device (eg, /dev/calcnet) whose destination can be set/altered with ioctl(). Actually I'm trying to think how it could be incorporated into networking since CALCnet doesn't have port numbers or anything else to determine which process owns each packet, so it'll be limited to a single process at a time. That's one reason I'm making my own protocol.

By the way, Kerm, I read that old MaxCoderz thread about the CLAP and your own development of CALCnet. It's an interesting read, and it makes me think that Chrisnet (the working name for my frame-level protocol) is to CALCnet as CALCnet is to the CLAP. They are similar at the low level in some ways, but they have different designs because they serve different purposes. So Chrisnet is not competing with CALCnet, just as CALCnet was not competing with the CLAP.
_________________
Christopher Williams

[KermMartian]

Fair enough. I actually do plan to have "port" numbers with CALCnet 3, which could be as simple as a one- or two-byte hash based on the name of the program currently using CALCnet if the program doesn't explicitly declare a port. The biggest roadblock for me is figuring out how I'm going to hack that into CALCnet without breaking backwards compatibility. Currently my ideas center around something that will make CALCnet2 clients ignore all CALCnet3 packets and have CALCnet3 tag its special packets by using one of the unused bits in the high byte of the size word.
_________________

[christop]

Can Doors CS have more than one program running simultaneously? I didn't know that. So currently only one program can use CALCnet at a time, I presume?

I would set bit 14 of the payload length to indicate a Cn3 packet. To Cn2 clients, it will look like a payload larger than 16384 bytes, and Cn2 clients already ignore payloads larger than 256 bytes. Then send the port number immediately after the payload length.
_________________
Christopher Williams

[KermMartian]

[christop]

[KermMartian]

Yeah, but the problem is not directed frames, but the broadcast frames that most programs use to find which other calculators on the same CALCnet network are running that program.
_________________

[ParkerR]

Great read. I think I actually learned a little bit from the whitepaper. Some possible mistakes I noticed.

Page 2 Line 3 Word 7 s/modications/modifications/
Page 2 Line 16 Word 8 s/my/by/
Page 2 Line 34 Word 5 r/period after Messrs
Page 5 Line 2 /send/sent/

[KermMartian]

Nice catches, ParkerR; if and when I update the whitepaper for future versions of CALCnet, I will certainly fix those. Out of curiosity, what sort of things did you learn from the Whitepaper that you didn't already know about CALCnet?
_________________

[ParkerR]

It was more of getting a grasp of the basics of low level networking. Honestly I didn't understand it all, but I feel like I came out with a greater appreciation of Calcnet and the people behind it. Great work.

[KermMartian]