I took a look at the current information on how IOU communicates.
It encapsulates the packet data with 8 bytes to indicate the communication path.
Making dynamips communicate directly with IOU instances should be doable, it just needs it's own iou_id.
Is there interest in this? Considering GNS3 already has iouyap and there are other scripts that bridge IOU<->udp/tap, it might not be worth doing.
- Linux images have more problems than sparc images. This is probably due to endianess issues. The ppc32/mips64/sparc cpus are typically big endian, and x86 is little endian. It's very easy to forget to byte swap data somewhere, which is the likely cause of the bugs in the linux images. (it's also very hard to debug)
- We know they communicate with unix sockets (local, default) and udp sockets (remote). Considering it uses unix features and was developed in a unix environment (Solaris?), I wouldn't be surprised if they also used IPC to communicate (Interprocess Communication Facilities, sys/shm.h and company). In this case I would expect a file in "/tmp/netio<uid>/" that is used to get the shared key with ftok.
- Since it's an encapsulation protocol, it's probably always 8 bytes. Which means the "fixed delimiter" (01 00) at the end is not a delimiter, but probably 2 individual bytes with unknown meaning. (ethernet/serial/...? command? needs experimentation).