After a little thought about the throughput of the network (ok, I havent
got 'that far', but I like to plan ahead), I am thinking we can get
increased speed with more data moved between nodes and less transitions
(input to output) than going around the ring with each node's data
(packet->in/out/in/out/in/out ->next packet)...
Here is my exmaple of two methods with six nodes (again based on the
game but it translates for a peer-to peer arrangement too.) Best viewed
in a monospaced font.
First method:
round robin separate processing for each player
5 data in 5 data out, per node, per game turn
[detrmine node number]
1 start [if first node (0) then goto 9]
**main loop
2 get data from upline
3 are we at the end of the ring? [yes, goto 5]
4 send data downline
5 main game routine [process player data (node x)]
6 end of game? [yes, goto 11]
7 cycle 'active node' counter
8 is it my turn? [no, goto2]
** update display here **
9 get 'local' action from keyboard/joystick
10 convert to data then goto 4
11 finish game
Refined method, share data first then process all
1-2 in 1-2 out, per node, per game turn
* This is assuming that repeated small network transfer would be slower
than bulk-transferring and processing all the turns.
[determine node number]
1 get 'local' action
2 [if first node in this round, goto 6]
4 [if last node in this round, goto 7]
5 get data of earlier nodes
6 send data of any early nodes with 'our data'
7 get data of 'later nodes'
9 pass on data of later nodes omitting the 'next node'
10 process all the data together
** update display here **
11 end? [yes, goto 14]
12 reduce the 'firstnode' and 'lastnode' by 1
13 goto 1
14 finish game
The distibution process looks like this:
node in-round1 out-round1 in-round2 out-round2
First- 0 0 12345 2345
1 0 01 2345 345
2 01 012 345 45
3 012 0123 45 5
4 0123 01234 5
Last- 5 01234 012345
As you can see it gives the last node the advantage as it only had to go
through one in-out cycle, and is the first to process while the one
before it will have to wait till the end, so if we then assigned the
lastnode as 'start' it could be ready to send by the time the previous
firstnode was ready to recieve (and give the second to last time to process).
As far as other peer-to-peer applications, by bundling 'packets
originated' with 'packets to transfer' similar savings could result,
though it increases the need for significant buffer space.
Of course this got me excited about file serives, file transfers,
application services and the like but the main drawback to this topology
is if one computer drops out (like when we have to cycle the power to
exit a game), the net will need to automatically reset and recover
somehow (after the computer comes back on and the NOS is re-loaded on
it...). This is where ethernet has the advantage as you can join and
unjoin from the network without upsetting the data flow, as everyone
taps into a common 'ether'.
--
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.