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.