Evil Network Tunnel?
I am looking for a tool to help me simulate a badly behaved TCP/IP network connection. I want to simulate a network with high latency, low bandwidth, frequent bit errors, and occasional drop-outs. This will help me test some software I'm writing. The idea would be to take this: Server Software - My Client Software And turn it into this: Server Software My Evil Tunnel --- My Client Software I want to be able to tell the evil tunnel to drop all data after sending N bytes, or to randomly drop 1 out of every N packets, or to introduce N ms of latency on all packets, or to throttle bandwidth to N bits/second. The idea is that I can test my client software for robustness in the face of degraded network connections. Does such a tool exist? Thanks! --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
No, but you could easily write a tool that can do any behavior you want between stdin and stdout, then wire it up on both ends via netcat. Or simply do the socket code yourself :) You could also get clever with iptables. Sounds like it could be a useful project. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Tue, Apr 12, 2011 at 11:57:48AM -0600, Dave Smith wrote: I am looking for a tool to help me simulate a badly behaved TCP/IP network connection. I want to simulate a network with high latency, low bandwidth, frequent bit errors, and occasional drop-outs. This will help me test some software I'm writing. I think the magic words you're looking for are netem and tc: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem If you're doing it all on one machine, you have to be careful about routing. If you have two ports, 192.168.1.1 and 192.168.2.1 linked by a tunnel, and you send a packet from 192.168.2.1 to 192.168.1.1, the kernel gets clever and realizes that it doesn't need to go through the tunnel. If I remember correctly, Google contributed a kernel patch that lets you disable this optimization. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Slightly OT: Bluetooth to replace USB?
At work we develop devices that communicate over USB with custom software, and are considering replacing the USB link with a bluetooth one. Thought I'd ask here if anyone has experience with such a transition, and could recommend a particular hardware path or approach? We need something that is cross platform, and would prefer drop-in replacement for current USB, which is handled by an on-board FTDI chip. Thanks! - Kimball http://www.kimballlarsen.com /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Tue, Apr 12, 2011 at 12:37 PM, Andrew McNabb amcn...@mcnabbs.org wrote: On Tue, Apr 12, 2011 at 11:57:48AM -0600, Dave Smith wrote: I am looking for a tool to help me simulate a badly behaved TCP/IP network connection. I want to simulate a network with high latency, low bandwidth, frequent bit errors, and occasional drop-outs. This will help me test some software I'm writing. I think the magic words you're looking for are netem and tc: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem If you're doing it all on one machine, you have to be careful about routing. If you have two ports, 192.168.1.1 and 192.168.2.1 linked by a tunnel, and you send a packet from 192.168.2.1 to 192.168.1.1, the kernel gets clever and realizes that it doesn't need to go through the tunnel. If I remember correctly, Google contributed a kernel patch that lets you disable this optimization. The netem thing looks cool. I also did some research into this, though more for creating virtual networks of virtual machines than for creating poorly-behaved network links. You might be interested in a couple of projects: Virtual Network User Mode Linux: http://neweb.dit.upm.es/vnumlwiki/index.php/Main_Page VirtualSquare Project: http://wiki.virtualsquare.org/wiki/index.php/Main_Page VirtualSquare Virtual Distributed Ethernet: http://wiki.virtualsquare.org/wiki/index.php/VDE The VDE thing looks like it's exactly what you asked for, especially with the wirefilter component, though Andrew's suggestion may be closer to what you want, depending on what it is that you do want. :) --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On 04/12/2011 12:37 PM, Andrew McNabb wrote: I think the magic words you're looking for are netem and tc: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem If you're doing it all on one machine, you have to be careful about routing. If you have two ports, 192.168.1.1 and 192.168.2.1 linked by a tunnel, and you send a packet from 192.168.2.1 to 192.168.1.1, the kernel gets clever and realizes that it doesn't need to go through the tunnel. If I remember correctly, Google contributed a kernel patch that lets you disable this optimization. I've been using tc/netem to do things *like* this, but it has a few drawbacks: 1. tc requires root access 2. tc is sophisticated (does a *lot* more than I want) 3. tc has a tricky command line interface I'm thinking this might be a good stand-alone executable that would be well suited to Google Go. Will report more later if I can. --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On 04/12/2011 12:07 PM, Nicholas Leippe wrote: No, but you could easily write a tool that can do any behavior you want between stdin and stdout, then wire it up on both ends via netcat. Or simply do the socket code yourself :) Indeed, but I want it to be transparent to my TCP/IP client application, so stdin/stdout are, well, out (pun intended). The latter option of creating my own is tempting, but I really wanted to find out if something like this already existed before embarking. --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
I've used a FreeBSD box with a kernel extension as an intermediate bridge. The parameters for the connection are then configurable on the FreeBSD box, including bandwidth limiting and dropping packets, etc. I don't remember the name right now but I will look it up and get back to you. At one point we also had a python webservice running on the FreeBSD box that could configure the options on the fly. -Richard Holden On Tue, Apr 12, 2011 at 1:00 PM, Dave Smith d...@thesmithfam.org wrote: On 04/12/2011 12:07 PM, Nicholas Leippe wrote: No, but you could easily write a tool that can do any behavior you want between stdin and stdout, then wire it up on both ends via netcat. Or simply do the socket code yourself :) Indeed, but I want it to be transparent to my TCP/IP client application, so stdin/stdout are, well, out (pun intended). The latter option of creating my own is tempting, but I really wanted to find out if something like this already existed before embarking. --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */ /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Tue, Apr 12, 2011 at 12:59 PM, Dave Smith d...@thesmithfam.org wrote: I've been using tc/netem to do things *like* this, but it has a few drawbacks: 1. tc requires root access 2. tc is sophisticated (does a *lot* more than I want) 3. tc has a tricky command line interface I'm thinking this might be a good stand-alone executable that would be well suited to Google Go. You're going to either need root to create tun/tap devices, or you'll need to virtualize the system your code runs on so that the virtual machine presents an ethernet device that really connects to some sort of pipe. If you're okay with using root access to create a couple of tap/tun devices, you could easily link them with a simple program. Here's a tutorial: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ But the time it would take to write a program to create a lossy tunnel probably outweighs whatever time you would spend configuring something like tc. On a tangent, looking up the pages about VDE led me to this amazingly cool little utility, which I will be downloading immediately: http://www.dest-unreach.org/socat/doc/socat.html --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Slightly OT: Bluetooth to replace USB?
On Apr 12, 2011, at 1:46 PM, Jonathan Duncan wrote: On 12 Apr 2011, at 12:44, Kimball Larsen wrote: At work we develop devices that communicate over USB with custom software, and are considering replacing the USB link with a bluetooth one. Thought I'd ask here if anyone has experience with such a transition, and could recommend a particular hardware path or approach? We need something that is cross platform, and would prefer drop-in replacement for current USB, which is handled by an on-board FTDI chip. I assume that you already understand that the transfer rate for Bluetooth is much slower than USB. This may not matter to your software, but should at least be something you are aware of. Yup, we are aware of the speeds involved... we don't need high bandwidth at all. We just toss a few bytes back and forth at a time. - Kimball http://www.kimballlarsen.com /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Tue, Apr 12, 2011 at 01:36:01PM -0600, Levi Pearson wrote: On Tue, Apr 12, 2011 at 12:59 PM, Dave Smith d...@thesmithfam.org wrote: I've been using tc/netem to do things *like* this, but it has a few drawbacks: 1. tc requires root access You're going to either need root to create tun/tap devices, or you'll need to virtualize the system your code runs on so that the virtual machine presents an ethernet device that really connects to some sort of pipe. I agree with Levi's statement. Dave, is there a way to get around having root access that I haven't thought about? The only thing that I could think of would be using a network simulator like ns or omnet, but I think network simulation would pair poorly with what you're trying to accomplish. 2. tc is sophisticated (does a *lot* more than I want) Then just use part of it. :) 3. tc has a tricky command line interface I'm thinking this might be a good stand-alone executable that would be well suited to Google Go. If you're okay with using root access to create a couple of tap/tun devices, you could easily link them with a simple program. Here's a tutorial: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ A nice tool to configure tunnels and netem would be really interesting. I envision such a tool tying in with the netem functionality in the kernel, and it wouldn't necessarily need to use tc. But it sounds like maybe Dave has something else in mind. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Slightly OT: Bluetooth to replace USB?
On Tue, Apr 12, 2011 at 1:47 PM, Kimball Larsen kimb...@kimballlarsen.com wrote: At work we develop devices that communicate over USB with custom software, and are considering replacing the USB link with a bluetooth one. Thought I'd ask here if anyone has experience with such a transition, and could recommend a particular hardware path or approach? We need something that is cross platform, and would prefer drop-in replacement for current USB, which is handled by an on-board FTDI chip. I assume that you already understand that the transfer rate for Bluetooth is much slower than USB. This may not matter to your software, but should at least be something you are aware of. Yup, we are aware of the speeds involved... we don't need high bandwidth at all. We just toss a few bytes back and forth at a time. Bluetooth is a rather heavyweight protocol, and you might end up adding a lot of cost unnecessarily. Do you need the flexibility of Bluetooth, or would a lightweight but non-standardized RF transceiver work for you? A lot of wireless keyboards and mice work this way, using a tiny RF to USB dongle to link to the PC. This part looks like a popular solution in this space: http://www.nordicsemi.com/jpn/Products/2.4GHz-RF/nRF24L01P They've got a dev kit for it that goes for a few hundred bucks, but Sparkfun has some much simpler boards based around it for much cheaper if you want to do a cheap prototype or experiment. --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
I realize this answer is a bit late and probably isn't quite what you are looking for, but I recently did something similar for a client. What I did was pretty simple, establish 2 connections and toggle between the two. First pick a stable connection source, fiber, cable, DSL what have you. Then pick a high latency connection with significant packet loss, Satellite, WiMax/3g (Clear or Sprint in a weak area or indoors for instance), etc. Once you establish a base line on the good connection, you can toggle at will to the more fragile connection and compare the differences. Furthermore if 802.11a/b/g/n are options for your testing environment, an even simpler solution might be to run the test(s) directly connected to the router or immediately adjacent to it, with high signal power vs turning the router output power down to the bare minimum, on a noisy channel, and putting some distance between yourself the router to weaken the signal as much as possible. This option allows you to test semi-real world scenarios and lets you see how environmental factors will affect packet loss. Obviously the second option only tests behavior on a single connection type but it does make it easy to have fairly granular control over your testing regime while still evaluating close to real world scenarios. Anyways, the group probably has better solutions, but these ideas are what immediately came to my mind and I didn't see anything about stressing the connection itself, so I figured I'd chime in. Sincerely, Steve /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Slightly OT: Bluetooth to replace USB?
Have you considered looking at something like this as a basis for transition? SYBA (SY-ADA23012) USB Bluetooth 2.0 + EDR Dongle, CSR Chipset http://www.newegg.com/Product/Product.aspx?Item=N82E16833328011nm_mc=OTC-Frooglecm_mmc=OTC-Froogle-_-Network+-+Bluetooth-_-Syba-_-33328011 I know it's not exactly what you are looking for, but it would leverage your existing investment in USB by providing a direct translation layer. Obviously most of the heavy lifting on that device is in the driver, but the chipset it's built on is extremely flexible and without violating any of my NDA's, I believe I can safely say it is used in a broad array of products from significant manufacturers. Also the dongles are only $6.99 and would probably be even cheaper with volume. As for advice, the main thing with bluetooth to be aware of (having worked on a USB to bluetooth conversion for a major product line), is that there are different device profiles and each serves a very distinct purpose, but there can be quite a bit of confusion as to which is best for a particular application. To remain standards compliant you will want to take significant time to decide what exactly it is that your device does, and carefully consider which profile(s) you want to support with your device. A quick run down of various device profiles are located here http://en.wikipedia.org/wiki/Bluetooth_profile A higher level of detail is located here. https://www.bluetooth.org/Technical/Specifications/adopted.htm I hope you find this helpful! Sincerely, Steve /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On 04/12/2011 11:57 AM, Dave Smith wrote: I am looking for a tool to help me simulate a badly behaved TCP/IP network connection. I want to simulate a network with high latency, low bandwidth, frequent bit errors, and occasional drop-outs. This will help me test some software I'm writing. In the past I have literally spent man-months building user-space programs that would simulate network behavior. Today, there is a simple approach that would have saved me most of that effort: full virtualization. With KVM or VirtualBox or whatever, you can build a virtual network and use all the kernel-space networking features to route, queue, drop, and mangle packets with ease. Look at it this way: where can you find the best open source Internet packet processing software? I say it's in the kernel (Linux or BSD). It would be nice if someone were to copy the packet processing from the kernel into some user-space daemon, but until that happens, full virtualization is a good way to treat a kernel as a user-space program. Shane /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Slightly OT: Bluetooth to replace USB?
We have considered this, but some of our target devices may not have a USB port in the first place (tablets, etc) but do offer built-in bluetooth. Great idea though - thanks! - Kimball http://www.kimballlarsen.com On Apr 12, 2011, at 2:02 PM, Levi Pearson wrote: On Tue, Apr 12, 2011 at 1:47 PM, Kimball Larsen kimb...@kimballlarsen.com wrote: At work we develop devices that communicate over USB with custom software, and are considering replacing the USB link with a bluetooth one. Thought I'd ask here if anyone has experience with such a transition, and could recommend a particular hardware path or approach? We need something that is cross platform, and would prefer drop-in replacement for current USB, which is handled by an on-board FTDI chip. I assume that you already understand that the transfer rate for Bluetooth is much slower than USB. This may not matter to your software, but should at least be something you are aware of. Yup, we are aware of the speeds involved... we don't need high bandwidth at all. We just toss a few bytes back and forth at a time. Bluetooth is a rather heavyweight protocol, and you might end up adding a lot of cost unnecessarily. Do you need the flexibility of Bluetooth, or would a lightweight but non-standardized RF transceiver work for you? A lot of wireless keyboards and mice work this way, using a tiny RF to USB dongle to link to the PC. This part looks like a popular solution in this space: http://www.nordicsemi.com/jpn/Products/2.4GHz-RF/nRF24L01P They've got a dev kit for it that goes for a few hundred bucks, but Sparkfun has some much simpler boards based around it for much cheaper if you want to do a cheap prototype or experiment. --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */ /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Slightly OT: Bluetooth to replace USB?
On Apr 12, 2011, at 2:30 PM, Steven Morrey wrote: Have you considered looking at something like this as a basis for transition? SYBA (SY-ADA23012) USB Bluetooth 2.0 + EDR Dongle, CSR Chipset http://www.newegg.com/Product/Product.aspx?Item=N82E16833328011nm_mc=OTC-Frooglecm_mmc=OTC-Froogle-_-Network+-+Bluetooth-_-Syba-_-33328011 I know it's not exactly what you are looking for, but it would leverage your existing investment in USB by providing a direct translation layer. Obviously most of the heavy lifting on that device is in the driver, but the chipset it's built on is extremely flexible and without violating any of my NDA's, I believe I can safely say it is used in a broad array of products from significant manufacturers. Also the dongles are only $6.99 and would probably be even cheaper with volume. As for advice, the main thing with bluetooth to be aware of (having worked on a USB to bluetooth conversion for a major product line), is that there are different device profiles and each serves a very distinct purpose, but there can be quite a bit of confusion as to which is best for a particular application. To remain standards compliant you will want to take significant time to decide what exactly it is that your device does, and carefully consider which profile(s) you want to support with your device. A quick run down of various device profiles are located here http://en.wikipedia.org/wiki/Bluetooth_profile A higher level of detail is located here. https://www.bluetooth.org/Technical/Specifications/adopted.htm I hope you find this helpful! Sincerely, Steve Steve, This is excellent information. Thank you very much! - Kimball http://www.kimballlarsen.com /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On 04/12/2011 12:59 PM, Dave Smith wrote: 1. tc requires root access As far as simulating packet loss, you will need to root to do this anyway, since you'll have to be working at a very low level (below tcp/ip anyway). TCP/IP, of course, does not just lose bytes, so simulating loss at the socket level is not going to work. UDP is another matter of course. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Tue, Apr 12, 2011 at 4:41 PM, Michael Torrie torr...@gmail.com wrote: On 04/12/2011 12:59 PM, Dave Smith wrote: 1. tc requires root access First off I have to fall on my sword for top posting earlier. Second, I think all solutions are going to require root, but it depends on what you need to have root on. The project I used in the past was dummynet http://info.iet.unipi.it/~luigi/dummynet/, and apparently they now have a Linux version, so no need for FreeBSD if you don't want it. I've had good success using this as a bridge/gateway into a lab of around 40 systems where each could be individually tuned. -Richard Holden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
Have you considered WANEM ( http://wanem.sourceforge.net/ ) ? From the homepage ... WANem thus allows the application development team to setup a transparent application gateway which can be used to simulate WAN characteristics like Network delay, Packet loss, Packet corruption, Disconnections, Packet re-ordering, Jitter, etc. WANem can be used to simulate Wide Area Network conditions for Data/Voice traffic and is released under the widely acceptable GPL v2 license. Please let us know what you find as a useable solution. Kenny Long /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
Thus said Dave Smith on Tue, 12 Apr 2011 11:57:48 MDT: I am looking for a tool to help me simulate a badly behaved TCP/IP network connection. I want to simulate a network with high latency, low bandwidth, frequent bit errors, and occasional drop-outs. This will help me test some software I'm writing. What about Burrow: http://wiki.tcl.tk/3929 I suppose it's a proxy of sorts, but it's written in Tcl and should be easily extended to programmatically do what you want. Andy /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Apr 12, 2011, at 1:47 PM, Andrew McNabb wrote: On Tue, Apr 12, 2011 at 01:36:01PM -0600, Levi Pearson wrote: I agree with Levi's statement. Dave, is there a way to get around having root access that I haven't thought about? The only thing that I could think of would be using a network simulator like ns or omnet, but I think network simulation would pair poorly with what you're trying to accomplish. Yes. I'm proposing a user-land executable (like socat) that listens for connections on localhost, say, port 8000, and forwards the data received to a user-specified remote host/port (like ssh -L, minus the encryption/authentication), and does user-configurable naughty things to the bits while in transit. My primary use case is dropping all data after N bytes are transferred to simulate an otherwise undetectable network outage. I intend to put this to work in our continuous integration test suite so our software is constantly getting validated against unfavorable network conditions (we already do testing against DNS timeouts, unresponsive hosts, and other stuff that's easier to simulate with quick hacks to /etc/resolv.conf and /etc/hosts). Peter McNabb actually showed me some ways that iptables can do what I want with its statistics module (connbytes and TARPIT), which when used in conjunction with tc, would be pretty cool. Clearly, methods exist to do what I want, but it looks like all of them involve pulling together multiple tools. Wouldn't it be great to do this with a single executable and a simple command line interface? Must. Resist. Temptation. To. Reinvent. Wheel... (but my wheel would be so much shinier! quoth the village software idiot) --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Apr 12, 2011, at 4:41 PM, Michael Torrie wrote: On 04/12/2011 12:59 PM, Dave Smith wrote: 1. tc requires root access As far as simulating packet loss, you will need to root to do this anyway, since you'll have to be working at a very low level (below tcp/ip anyway). TCP/IP, of course, does not just lose bytes, so simulating loss at the socket level is not going to work. UDP is another matter of course. I don't think so. See my most recent post. --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On Apr 12, 2011, at 6:31 PM, Kenny Long wrote: Have you considered WANEM ( http://wanem.sourceforge.net/ ) ? From the homepage Very interesting. --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Evil Network Tunnel?
On 04/12/2011 09:09 PM, Dave Smith wrote: I don't think so. See my most recent post. Is your app using UDP or TCP/IP sockets? I guess if it's designed to work on flaky network connections and do its own error detection, it's probably UDP. If you try to mess with the TCP/IP socket connection you'll likely just end up with a hung process (or if you are using ASYNC communication, a timeout). You won't get corruption outright as TCP/IP will ensure that packets are retransmitted. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
