Asynchronous RJ45 EthernetUsing typical cat5-6-7 cable we want to implement a asynchronous protocol that can scale from 100bytes a second requiring less than 1 mhz all the way up to as fast as you can push content over the copper.
Compatible with current standers ie 10BASE-T 100BASE-TX 1000BASE-T
Run on arduino or equivilant require less than 1 mhz with no additional hardware
Use all current congestion and routing control
Use multiple lines for more speed
Direct connection bypass switches/routers just computer2computer or microcontroller2computer
Full duplex transmission
(future) Full hardware implementations
Secure line intrusion prevention similar to tls on the actual transport layer!
Fully offloaded checksuming, TCP, UDP, and ICMP
Built in stack memory requiring none of the systems
$10 10gbps pcie card
$100 100gbps pcie card
$500 8 port 100gbps router
Lower latency than clock based
Lower power usage lines can draw near 0 when not in use
More bandwidth - hardware permitting
Variable CPU usage - if a microcontroller is busy it can drop the cpu usage and use for something more important
Compatible with existing infastructure - makes much easier rollout
Only use the same data lines as ethernet standerds
Same power over ethernet
Same line voltaes as ethernet
Same distance as ethernet at same speeds but can extend further at a drop in speed
Stage 1 - Design (incomplete last update Dec-5-2011)
We need to work on the autonegotian and failback methods. This stage will be complete when data can be sent asyncronously and fallback to 1000 100 and 10 baset.
Stage 2 - Implementations
In this stage we are going to be looking more at clock usage and get some status on how much data we can get a arduino to send using less than 1mhz of its processing power.
Stage 3 - Direct communication
This stage we get a arduino directly communicating with a computer. No router/switch/infastructer
Stage 4 - Hardware
Here we design a fpga implementation and asic design that will be < $10usd
Stage 5 - Infastructure
The final stage router/switch devices.
The linux community has typically been against TCP off loading but with this protocol we are hoping that will change.
Security - The firmware must be updated instead of software. While yes this does remain true the protocol is open source along with the firmware making it just as good as software implmentations
Limitations of hardware - This is the case of any device even the main system. With the asyncrounous design hitting a hard limit on the hardware will slow the traffic but everything will flow as usual. In almost all cases by offloading the main cpu can be left for other things and actually be less limiting.
Complexity/Proprietary - Being an open protocol with open source hardware makes this less complex infact it can conform to other standards and even have multiple modes if someone spent the time to program them. We are using a different approach to tcp offloading and networking entirely but we are keeping things very simple and very generic so implementation should be a breeze.
Obsolescence - Everything has a limited lifespan of usefullness your cpu included so why is this scrutinized? We say mainly because of the money factor but we overcome that by making this at or around typicial network hardware costs.