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 email@example.com.
Archive generated by hypermail 2.1.1.