in reply to A Perl-based Transparent TCP Proxy (TPROXY and POE)
POE is basically a Finite-State Machine engine. It works well in this case because it describes each conversation using a relatively small storage record (a “session”). The maximum number of incoming packets is determined by the number of ports, and perhaps really by the number of network interfaces, that are being listened to. The actual CPU-driven response to each packet is so trivial as to be almost non-existent. A system like POE, unlike processor threads, puts all of that status information on one great big electronic “tote board,” namely the current state of all those sessions. Everyone can see everything. Certainly, POE itself can. Adjustments can be made easily. There’s no duplicated resources and no complex timing-holes. At any instant in time, every conversation, except the one for the most recently-received packet, has nothing for the CPU to actually do on its behalf.
In a very large dining room full of many hundreds of people, how many employees are there? Perhaps only a few dozen. When someone comes in and sits down at a table, a new order-ticket will eventually be created, but not an entire new set of employees. What works well when you go out to eat, also works in a TCP proxy. Imagine the chaos that would occur in a restaurant if there was a box by the door full of little boxes, each labeled “instant employee, just add water,” and that is how you got your dinner. (The employee pops into existence, takes your order, wades into the kitchen with the hundreds of others, dukes it out fighting to get access to the grill and so-on, eventually comes back with your food, then falls dead.) If you instantly (and instinctively) know such a thing could never work in a restaurant (even if it were possible), you also know it would not work in other settings for which it is, technically, “possible.”