> You'd need some plumbing in devether to demultiplex incoming > packets addressed to this device (assuming it has its own MAC > address).
i don't think you would. if you're using the latency device as your ethernet device, no muxing is required. > Something like a tap device would allow you to simulate high > latency link, a level-2 bridge or whatever in usercode. this is difficult to do in user space for two reasons 1. the difficulty of getting precision timing. 2. copies into/out of the kernel. > [BTW, is there a strong reason why devether.c is in 9/pc/ and > not 9/port/? vlan code can be factored out from various > ether*.c to a similar portable file (if not devether.c)] actually, most of the code has been factored out, but one step better than you imagine. most of the code is in ../port/netif.c which should be a good start on any type of network interface. what remains is code littered with system dependencies. it's worthwhile comparing pc/devether.c with kw/devether.c by the way, there is no vlan code, as far as i know, which is absolutely fine by me. > > ip is not the only protocol! that's what loopback(3) does, but without > > the real network. it would be good to plug loopback or similar into a real > > ethernet. it's also worth looking at loopback's implementation strategy, > > Or bridge(3). not sure that is too informative. > > which allows for µs delays. sleep is just too course-grained for my > > testing. > > > > dialing up random reordering would seem to me to be a feature at > > this level. > > A user level simulator will make it easy to add random drops, > reordering, filtering, NAT, etc. what do you mean by mac-level natting? something like hp vc? seems way too extravagant for a simple packet muncher. by the way, if you keep the packets in the order they should be released from the delay queue, reordering is automatic. i suppose the delay queue gives new meaning to the term "storage network". - erik
