Recently I have been contemplating what future Arduino networking might look like on 32 bit microcontrollers.
Today we seem to have a huge capability gap between microcontrollers and Linux-based boards. Obviously 8 bit AVR with 2K to 8K RAM and polling-based I/O imposes pretty severe limitations on the microcontroller side. On the Linux side, obviously you get fully featured networking with daemons for nearly all protocols and powerful networking client software, but the cost is dozens (or hundreds) of megabytes of RAM and a powerful (power hungry) processor.
In the not-too-distant future, as semiconductor manufacturers move microcontrollers to 65nm and even 45nm transistors, we'll get Cortex-M microcontrollers with 256K to 2M RAM, running in the 200 to 500 MHz range, with on-chip DMA-based ethernet MACs and wireless networking. Even now, chips like the SAM3X on Arduino Due have high performance ethernet just sitting unused, but there's little point to connect the pins because of lacking software support.
My hope is to design networking layer / stack / libraries that fills the gap, with good performance and a fairly easy path to build a project with a variety of networking services, but scaled appropriately to near-future microcontrollers where 20K to 100K RAM usage is acceptable.
Concurrency is certainly a big issue. There are a lot of complex technical choices, but as far as I can envision, they always boil down to three possible paths for the design of how future sketches would actually accessing networking:
#1: Non-blocking functions, like Serial.available() and Serial.read()
#2: Blocking functions, like Serial.print() - requires I/O aware Scheduler or RTOS, segments RAM into tiny stacks
#3: Event-based structure imposed, like serialEvent()
Designing something powerful and easy to use that can work within the (near future) limitations of microcontrollers requires many difficult trade-offs. If you want everything, with all types of APIs and all possible features and fully preemptive scheduling and ... inevitably you end up with something like Linux, compromising the original goals of simple to use and able to run with limited resources.
I'm sure there are lots of opinions. I've love to hear yours!