[Embedlets-dev] peer to peer?
Status: Alpha
Brought to you by:
tkosan
|
From: Bruce B. <bb...@sy...> - 2003-06-27 19:10:38
|
At 01:48 PM 6/26/2003 -0700, you wrote: >From: "Gregg G. Wonderly" <gr...@sk...> >Reply-To: emb...@li... <snip> >Slaves in the ready-list are now ready to transfer packets between devices. >The ready-list thread would start clocking bytes from the slaves, and feeding >them any traffic that is destined for them. Each slave in the ready-list >would have a packet queue that would be composed of a several bytes of buffer >(slave count + a few should work). The packets from the slaves would >have, at >the front, a packet type identifier and a destination slave number. The data >would then be clocked, round robin, one byte at a time. The master would >transfer a byte to the slave, and take the return byte and process it. When >the slave indicated end of data, it would be put back in the poll list. > >This would give you a full peer to peer (via the master) and multi session >network that should be able to provide a high degree of flexibility using >SPI... I'm lost. Peer to peer either is or isn't. If there is one master then it isn't peer to peer since there's no peer-to-peer communication ever, only master-to-peer. I realize I'm stating the obvious but... If I grasp your idea (and I'm not sure I do) the master visits all the intelligent slaves, gets data packets from them, then redistributes any such packets which are intended to be sent from one slave to another. So the master is a "mailman". The master has to handle every packet twice, which could be done but will become a bottleneck at some point. There's no guarantee that a timely message will get through unless the overall loading is light and the polling is frequent. This could work, I suppose, but how does one node know another exists, and what services it can provide or consume? This is why there are true peer to peer nets such as CAN which contemplate such things. CAN is true peer to peer and will run at up to 1 MBit for short distances. It's also extremely robust. There are CAN protocols which could have this structure. The best peer to peer one of which I'm aware is CAN Kingdom. It's not a lightweight protocol. CAN is only suitable for a small local net. It would require a CAN controller chip such as MCP2510 or SJA1000. CAN guarantees that urgent messages get through quickly and in a bounded time. This is why it's used on antilock brake and fuel injection systems where there is little margin for error. JXTA also addresses similar issues and that's where we are going: http://jcx.systronix.com/rfmodems.htm since it works with or without wires and already scales from embedded devices to the internet. Maybe some subset of a JXTA peer could be used on a party line net like CAN (preferable) or I2C (less ideal but lower cost) to accomplish what you want? Bruce |