KermMartian wrote:
Yay Merthsoft! Merth has put the lion's share of work into this, and I'm proud of what he's done so far. Unfortunately, he'll probably need to maintain a list of network users the way NetPong does, but that's a discussion for another day.
Would this be a broadcast/timeout scheme of some sort?
elfprince13 wrote:
KermMartian wrote:
Yay Merthsoft! Merth has put the lion's share of work into this, and I'm proud of what he's done so far. Unfortunately, he'll probably need to maintain a list of network users the way NetPong does, but that's a discussion for another day.
Would this be a broadcast/timeout scheme of some sort? Aye, I'm thinking that calcs can periodically broadcast to announce their presence, and each calculator can maintain what's essentially a single-link list of online calcs. When you send a line, you send it to each calc on that list sequentially; if any fails to respond in 1 or 2 seconds, you remove it from the list and skip to the next one.
perhaps just a vector or hashtable of some kind in a reasonably sized buffer? I feel like growing/shrinking a list, and the memory management required would be more work than it was worth.
elfprince13 wrote:
perhaps just a vector or hashtable of some kind in a reasonably sized buffer? I feel like growing/shrinking a list, and the memory management required would be more work than it was worth.
Oh, don't worry, I'm talking about a fixed-sized buffer here. I don't want to make Merth's life any harder than it needs to be
I think what I'm going to do is have a server calc that handles all of that, that way only one calculator has to handle joining/parting.
merthsoft wrote:
I think what I'm going to do is have a server calc that handles all of that, that way only one calculator has to handle joining/parting.
Sounds like a plan; that's sort of how NetPong works as well, in that it has one calculator, the leftmost one at position 1, handle alerting all other calculators when it's time to start playing. I however assume that no calculator disconnects while a NetPong game is in progress, or if it does, that the game be terminated. What would you do in CALCnet Chat if the server disconnects?
Also, regarding your PTI issues, I noticed that the "transmitting" debug pixels turn on when you hold down [down]. I'll keep searching.
If the server goes down, the clients will realize it, and just go back to sending out "HELLO?!"s until another server pops up.
*bump* So for the sake of speed of release for this program, Merth and I have decided to collaborate on Chat. MY current task is to eliminate his Users appvar, used for storing SID/username pairs, and find a SafeRAM area to use instead. If I try to use AppBackupScreen, and users are limited to 8-character names, then slots are 13 bytes each, and between ABS+129 and $9999, which is where the Cn2.2 interrupt stub lies in RAM, a total of 166 bytes, Chat could handle a maximum of 12 users. If we use $8A3A (StatsVars) instead, we have 512 bytes to work with, which is (512/13) = 39 users. Therefore, that's what I'm going to go with, and I'll use AppBackupScreen for other SafeRAM things like AppVar location buffering, known calculator counting, etc.
*Six hour administrator bump*
So today I did various clerical tasks on Chat, cleaned up a few things, made the messages sent get echoed back to the local client, made the local calculator store the local username (and cache it for future sessions), and prepend it to messages sent. Not yet done is any kind of more organized message transmission than spamming a broadcast message and hoping other calcs get it. Also not yet done is any population of the users list.
Awesome, Kerm. Looks great! I'm excited to see this project come to fruition
Thanks for taking it over (or at least, the hard parts).
merthsoft wrote:
Awesome, Kerm. Looks great! I'm excited to see this project come to fruition
Thanks for taking it over (or at least, the hard parts).
I'll do the networking stuff next, but I'm going to shrug off the annoying things like trimming the top of the scrollback to you.
*bump*
:: Decided three one-byte-prefixed frame types: (171) Broadcast "alive" ping; (172) Broadcast "disconnecting" ping; (173) Directed chat message
:: Started to add prefixing and receiving differentiation logic
:: Still to do: use 171 and 172 to maintain calculator list.
:: Still to do: on each frame receive, increment timeout byte of each calculator in data structure, remove "timed out" calculators as needed
:: Still to do: Make "user joined", "user disconnected", and "user timed out" messages appear
:: Still to do: Make sure 171 packets contain a username payload
:: Still to do: Make 173 transmission routine cycle through all known endpoints, also time out and remove calculators as necessary
:: Stuff for Merth to do: Automatically trim scrollback as new stuff gets added, avoid overflows. List contents in Names window. Handle scrolling a la DCS Libs' GUIMenu function.
Edit: Fleshed out network maintenance logic a bit. Punted on some issues with, for example, the triply-called "call IsSenderKnown".
Have you thought about the mechanism for name-switching yet? Will it just be a chat message that the other calcs interpret a certain way?
merthsoft wrote:
Have you thought about the mechanism for name-switching yet? Will it just be a chat message that the other calcs interpret a certain way?
Oh, I didn't think of that. Since there are explicit join broadcasts (which carry a username) and disconnect broadcasts (which do not carry a username), how about making a calculator changing its name broadcast a disconnect and a rejoin with the new name?
Or just make it part of the "alive" ping.
merthsoft wrote:
Or just make it part of the "alive" ping.
Yeah, but that might take a while; shouldn't the other calculators know immediately?
Have it send one out when you change names.
merthsoft wrote:
Have it send one out when you change names.
That's a good idea, but I'm not enjoying the mental prospect of doing a name comparison every time a ping frame arrives. Couldn't I just send the disco frame before the ping frame?
It could. But won't it display "blah blah disconnected" "blah blah blah connected"?
merthsoft wrote:
It could. But won't it display "blah blah disconnected" "blah blah blah connected"?
That's a very good point. We don't currently have connect/disconnect messages displayed; do you think that we should add that? I don't think it's a bad idea at all.