Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
[This is a Work in Progress]

CALCnet2 Ideas
---------------

Collisions: In order for collision detection to work properly, we should poll the link port a few times after setting it to check that it doesn't change state on its own. If it does, we'll know that for some reason another calc is trying to send at the same time. If this happens, any sending calc that notices this anomaly should do something to inhibit all communication on the line for several (u)s, then wait a random amount of time before trying again.

Ideas for what to do to inhibit communication: perhaps pull and hold the clock line? Then we could have any calc pulsing the clock line as it's sending check if the clock line is still high after it releases it. If it's still low, then someone else is holding it low. Also, the one inhibiting communication is going to have to _actively_ keep setting clock to low, since other ones might be trying to pull it high in the meantime. Ideally, all sending calcs will recognize that there was a collision even before the inhibit, but the inhibit is necessary if for some reason one calc notices and stops before the other one(s). If even one calc failed to notice the collision and kept transmitting, the integrity of the data being sent would be compromised. Also, the receiving calc needs to notice the inhibit as well (or at least notice that the clock line hasn't flipped) and discard any data in the current frame.

Ideas for acknowledgement of received frame: one idea would be to have the receiving calc do something to the clock line to acknowledge each bit, but that sounds kinda hard to synchronize. Instead, it might be good to have the pause time per bit sufficiently large that the read loop on the receiving calc could do several (3-4) iterations in the pause time to prevent missed bits. Then, when the frame is finished, the receiving calc should perhaps immediately send back a 32-bit checksum. If the sending calc believes it to be correct, it does nothing. Otherwise, it needs to send a discard frame/resending frame frame.

I believe at this point one of the hardest things is going to be making the receiving calculator realize it's being sent data. If the check for data method is an interrupt, as planned, then there is the problem of the relatively large amount of time between successive calls of the interrupt (roughly once every 46500 clock cycles). One way to do it would be to just make the sending calc hold the clock line low for about 100,000 clock cycles. That would almost guarantee that every other calculator's attention would be gotten, and it could then proceed with the address and the frame itself. The problem there is that a calc that notices the clock low pull near the beginning may have to wait outside of regular execution up to 1/60th of a second (0.167s) before the sending calc starts sending the address and the calc can safely ignore the data or recognize that it is the intended recipient. Possible workarounds or solutions for this?

Addresses: I was originally going to make CALCnet2 utilize a cascading checkin system that would have each calc in a network have a 1-byte identifier that determined both its position in the cascade check and its target address for transmissions from other calculators. However, it seems to me that the cascading checks would take a good deal of time and unnecessarily tie up network resources. I have been taking an informal networking class at my college, and as I was listening to some of the networking theory we are learning, I realized that whereas every single piece of computer networking equipment manufactured has a unique Media Access Control (MAC) address that identifies it, the calc does as well - the SID number! This 14-character (7-byte) string could be used as the CALCnet2 equivalent of the MAC address. The followup I am still considering, however, is whether I will also need to have a local CALCnet2 network (LCN) address, equivalent to a LAN IP address. At the moment I am inclined to think that I do not, and I'm trying to see if there's any reason that I would need such an address in addition to the SID.

Other Devices: Those non-calculator devices on a network necessarily do not have an inherint SID. Because of this, they must be given an artificial one. I pick A5A5A5A5A5A5A5 as the SID, since that has enough state changes to avoid any random problems, and is unlikely to be an actual SID of a calculator (too high of a number). This will make it extremely easy for a non-calculator host device to check if there is already such a service on the network. Simply send a ping frame to A5A5A5A5A5A5A5 and wait for a response. If there is no ping-response frame within one second, the device can safely assume it is the only such device on the network and begin to serve out ping, HTTP, gCn, and other services to calculators present.

gCn: By using the SID as the network identifier, it's easy to remove several layers of complexity from gCn. In order to send data to another calculator, the sending calculator might first send a ping frame to that SID. If there's no response, it may decide the calculator is not on the network. Next it pings A5A5A5A5A5A5A5. If there's no response, it returns an error to the program or user. Otherwise, if there is a ping response frame, it sends a gCn frame to the non-calc device with its full frame (recipient, sender, frame). The device can then send a messsage to all of the python servers via its own python server that goes something like: "hey, I'm looking for calculator so-and-so from so-and-so". The python servers notice the requesting calc and cache its non-calc device host's IP address, then ask each other where the receiving calc is. They may know where it is from previous where-is... requests, in which case the python serv can respond, "oh, it's an NN.NN.NN.NN". If not, they ask each of the connected hosts for that device. Each host pings its network; if no response, they send back a failed search message. The python servers give an address (if found) to the requesting host, which then contacts the reciving host directly. That host pings its network, and if it gets a response, it sends along the message to the calc as well as a confirmation message to the requesting host. If, however, the receiving host does not receive a ping response or at any time fails to receive an acknowledgement frame from the receiving calc, all it needs to do is tell the requesting host that the transfer failed, which the host will act upon by sending a "terminate send - connection to recipient lost" frame to the sending calc, and also by alerting the python server network that it no longer has a certain calc responding on its network. To summarize:
--the python server network attempts to cache IPs that each calc can be found at based on requests from hosts
--hosts alert the python servers when a calculator is no longer found on its network
--it seems that a ping service layered over Cn2 but lower than gCn is essential
--by doing things like this, gCn becomes effectively COMPLETELY transparent to the calculators themselves

This allows such things as seamless sharing of programs or files the same way between two friends or coworkers whether they are next to each other or on opposite sides of the world. In addition, it seems likely that Doors CS will contain some kind of fileservice. Calculators should be identified by their SID in any application, but by giving the host an option to search the PHP server for SID<-->username via the python servers, it may be possible to reference any calculator by its username in addition to its SID. Also, usernames should also be registerable to hosts, via IP and port, to allow them to act as file-, game-, or even (!) web-servers for globalCALCnet2.
With this setup, networks will no longer be limited at all. Local networks (LCNs) can range from anywhere between 2 and thousands of calculators. The only caveat is that the network load associated with thousands o fcalculators would necessarily slow down the network substantially. Keep in mind that there can be a maximum of 60 frames sent per second on a network, since the delay time is 100,000 clock cycles. This further underscores to me the need to eliminate or at lesat decrease that number somewhat; 60 frames per second sounds unacceptably low to me. Anyway, the simplest of CALCnet2 networks is two calculators directly connected via a link cable. in this "Direct Connect" mode, the sending calcultor would send a DC-type frame along the link cable with the recipient set to 00000000000000. The other calculator then realizes that the connection is a DC one and sends a file-listing frame to the requesting calc. It returns with a file listing frame, and the connection is established. Files can be transferrred over the DCFP protocol from Doors CS, consisting of send-var and get-var frames. Note that DC is an inherint feature of Cn2, whereas DCFP is merely an implementation built into Doors CS that runs over the Cn2 framework.

Preliminary Frame Type Listing:
-- DC-type
-- DCFP-send-var
-- DCFP-get-var
-- DCFP-file-listing
-- ping-request
-- ping-respond
-- Cn2-data \\__These two are not user-accessible: all other frametypes
-- Cn2-ack // are built into these two.

Preliminary Frame Format:
+--------------------+--------------------+-----+------------+
|Recipient SID------>|Sender SID--------->|Bytes|Data--- - ->|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
|0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
You really have thought this out, Kerm! Razz .
Actually, this was me sitting and rambling while I was copying and scanning stuff at work today. I'll be fleshing this out and clarifying it, as well as working out solutions to the various problems I mentioned in the first post.
Rolling Eyes Wow, you must have been REALLLY bored, 0x5.
I had had a lot of these ideas yesterday, and I wanted to get them down on paper, if you will, before I forgot about them. I think I'll try to work out the details of the bitlevel protocol so I can start making something for Kllrnohj and Elfprince to work on for gCn.
KermMartian wrote:
Preliminary Frame Format:
+--------------------+--------------------+-----+------------+
|Recipient SID------>|Sender SID--------->|Bytes|Data--- - ->|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
|0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+


Unless I am mistaken, the SIDs are a fixed length, correct? Is there going to be some sort of seperator between the number of bytes and the beginning of the data, or will the number of bytes be a fixed length? (as in it will always be 2 bits, for a max data length of 65536) Sending 65k of data over the link port is a bit extreme (and slow), so I'd figure that limiting data to 65k is reasonable.

Or, better yet, could a packet-style fixed-data length system be implemented? That way long file transfers won't necessarily tie up the network (or is that too hard to implement?) as all the packets don't necessarily have to be sent at the same time
It makes more sense in fixed-width font, this way:

Code:
Preliminary Frame Format:
+--------------------+--------------------+-----+------------+
|Recipient SID------>|Sender SID--------->|Bytes|Data--- - ->|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
|0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16|  |  |   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
As you can see, the SID is always 7 bytes (14 hex chars), and I was giving a 2-byte datalength. I don't expect individual frames to go past 255 bytes, but I was thinking I might as well have the extra length available for things like DCFP-send-var frames. I could do something like a fixed 64-byte packet within each frame, but I run the risk of wasting network time for things like pings, which only really need 3 or 4 bytes. I kept trying to paste this to you, but my wifi connection kept dying. Do you have any comments or suggestions, or stuff to add to this, Kllrnohj?
KermMartian wrote:
It makes more sense in fixed-width font, this way:

Code:
Preliminary Frame Format:
+--------------------+--------------------+-----+------------+
|Recipient SID------>|Sender SID--------->|Bytes|Data--- - ->|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
|0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16|  |  |   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
As you can see, the SID is always 7 bytes (14 hex chars), and I was giving a 2-byte datalength. I don't expect individual frames to go past 255 bytes, but I was thinking I might as well have the extra length available for things like DCFP-send-var frames. I could do something like a fixed 64-byte packet within each frame, but I run the risk of wasting network time for things like pings, which only really need 3 or 4 bytes. I kept trying to paste this to you, but my wifi connection kept dying. Do you have any comments or suggestions, or stuff to add to this, Kllrnohj?


I think the current system is fine. any data thats too long for a single frame should probably be split anyway. keep in mind that PIC variables, matrices, strings, programs, apps, appvars, and lists all tend to run above 255 bytes in length. Wink
KermMartian wrote:
It makes more sense in fixed-width font, this way:

Code:
Preliminary Frame Format:
+--------------------+--------------------+-----+------------+
|Recipient SID------>|Sender SID--------->|Bytes|Data--- - ->|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
|0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16|  |  |   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---+
As you can see, the SID is always 7 bytes (14 hex chars), and I was giving a 2-byte datalength. I don't expect individual frames to go past 255 bytes, but I was thinking I might as well have the extra length available for things like DCFP-send-var frames. I could do something like a fixed 64-byte packet within each frame, but I run the risk of wasting network time for things like pings, which only really need 3 or 4 bytes. I kept trying to paste this to you, but my wifi connection kept dying. Do you have any comments or suggestions, or stuff to add to this, Kllrnohj?


Sounds fine to me. It just appeared from the first one that the "Bytes" wasn't necessarily 2 bytes. Like elf said, there are plenty of things greater than 255bytes, so that is no way that is enough. 65k, however, should be plenty.

If the packet system is too hard, or too slow, to implement, that is fine. I was just suggesting another idea from the computer world Wink But I'm assuming you know that for a computer network, it doesn't ping to see if the host/client is there, instead, the sender assumes the receiver is there, sends the first packet, and the receiver sends an ACK packet back to the sender as a signal to send the next packet. Adopting that system would eliminate the need to ping first, as the first packet itself is the ping.
yeah, if for some reason your were sending a freaking huge, multipage, app there is no reason why you couldn't split the transimission.

also, the TCP and UDP wikipedia articles are very informative.
Re: size: but if you have a direct-connect connection, ie 1 to 1, there;s no reason not to send it in one fell swoop, especially since there's not much danger of noise on an 8-inch link cable. On the other hand though, if the checksum failed, you'd have to resend the whole thing, so maybe I'd be better off using [wow, look, a hot girl outside this Starbucks on her cellphone waiting for the rain to stop] a smaller frames when possible. Nevertheless, I'd like to have the option of frames larger than 255 bytes just in case they're ever needed.

Re: ping: yeah, but those networks also negotiate IP addresses to avoid any duplicates. Since the "IP" (ie SID) is negotiated in TI's factory, you have no way of knowing where a particular calculator is at any one time. Hence the necessity of each network pinging to find a specific calculator. Note once more that such a system is only completely necessary in gCn. In an isolated closed-area network, though, how else would you find other calculators? I'm still back at the conundrum of needing a way to find the other calcs on the network, some kind of network-wide "where is everybody"? Argh.
KermMartian wrote:
I'm still back at the conundrum of needing a way to find the other calcs on the network, some kind of network-wide "where is everybody"? Argh.

I've solved it this way with the way servers would be set up with PokéGen. A Master Server would sit and idle, waiting for connections. Mini-Servers would connect to it and let it know it's there. The Master Server would put its info in a server list. Clients could connect, request the server list and the client can choose one and connect to it. That way, one server doesn't have strain on it, there's always something up to say "Hey, let me help you find something to do" and people could set up their own servers for different things. That's just a sketch of what I plan on having PokéGen do. If you want more in-depth information, I can give it if you want.
Oh, Kllrnohj have all that kind of stuff figured out; we used a similar method to that. Within Cn2 isolated networks, however, there is no "server"; all the devices are peers. Hence the difficulty. Well, let me implement the basic protocol first. I finished writing it; now I need to compile, test, and debug.
since a normal Cn2 network is gonna be bunch of link cables in parallel

1) its a max of 60fps per network, not per calc,

2) every calc will receive every message so you'll be able to tell if you found them by seeing if you get a response from the desired SID
1) Technically correct
2) No - the receiver SID is the first thing sent; all calcs check it and don't bother listening to the rest of the packet if it's not for them.
theoretically they don't, hackers could exploit this viciously though if they write their own client...
Of course, but they can do the exact same thing with TCP/IP. It's also based on a trusted client model.
so now the only problem is finding other SIDs across gCn
That's not a problem; Kllrnohj and I worked that out at one point. The python servers will remember where they last saw an SID requesting data, then try to ping that calculator. If it responds, fine. If not, each Python servers will send a calculator request to each of the hosts it is serving, which will all ping that SID.
  
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 2
» All times are GMT - 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