This morning I thought of ring network transfers... This time I went beyond the game approach and thought of what would work for a mixed working environment, some computers transferring, others not, long downloads between several nodes, etc. Data should be in packets, to make the stuff more manageable (and give the non-net active systems some processing time.) I figure a variable length packet of 1 to 256 characters would be best (makes data easy to send/receive and move by a simple increment loop), also by making it at least 254 bytes makes moving disk blocks or memory pages less complicated.) preceding a packet would be three bytes, identifying the destination node, the source node and packet data length: 0=1 byte to 255=256 bytes. Sample structure (four byte packet from node 1 to 5): 005/003/001/000/255/034/001 Dst Len Src byt byt byt byt The reason for the length isn't the last header byte will be apparent later on. ;-) Now as I thought before, we would want to bunch up the packets going downline so each machine will need a 'transfer buffer', I figure for a basic start 5180 bytes or so, this would hold up to 20 full 259 byte packets - keeping it under 8k makes it a good candidate for 'under ROM' memory (since the transfer routine would not be based on the kernal or BASIC it is a good place to keep temp data, maybe even put some of the transfer code there too. Also we don't want it too big because we need to 'garbage collect' any unclaimed packets after transfer outs. Next up would be the transfer protocol (I'm kinda stuck on the mechanics, will worry about basic interfacing later...) So, our transfer program would be an IRQ routine, there would be three triggers to activate it: 1. incomming data from upline 2. request to send locally 3. log-jam resolved (this is the 'later') So the process would be: IRQ routine: Check for data waiting signal (either use the 'data arrived bit' or use PA6 as a flag from upline) Check for Local Send Request or packets to be sent count Verify absence of logjam [if either of the first two are set and the second is clear, go to the trransfer routine] [transfer-recieve] 1 receive packet dest from upline (clear PA6, they do too once it is sent) 2 is source $ff? yes, end if incomming, go to [8] 3 recive packet length from upline (compare with buffer pointer, space left?, if no, set PA6, log-jam) 4 receive packet source (this gives the sending computer a bit of time cefore cheking it's PA7 for a logjam) 5 logjam? if yes, go to send [8]. 6 If everything is ok, get data packet 7 go to 1 [transfer-send] 8 is there a logjam ahead? yes, go to [17] 9 send packet dest (and clear PA7) 10 send packet length 11 send source node# 12 check PA7 - log jam? if yes, go to [17] 13 everything ok, send packet 14 last packet? 15 yes, then send $ff and go to [17] 16 no, go to [8] 17 update local status registers, garbage collect and go back to irq wait. The local registers would be something like: * node# * max # nodes * buffer full/log-jam * free space? * waiting data (count?) I thought about letting small packets fit but if you bunched up a file transfer theoretically the end of the file could arrive before the source, so if the one packet to go doesn't fit no others should go past either. There are probably a couple holes, it needs some checks for local packets, maybe use a second 'receive buffer' for incomming local stuff, outgoing counters, a 'to all' broadcast packet ID, etc. but this is basically what I envision as the basic data-mover. -- 01000011 01001111 01001101 01001101 01001111 01000100 01001111 01010010 01000101 Larry Anderson - Sysop of Silicon Realms BBS (209) 754-1363 300-14.4k bps Classic Commodore pages at: http://www.jps.net/foxnhare/commodore.html 01000011 01001111 01001101 01010000 01010101 01010100 01000101 01010010 01010011 - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.