On Feb 19, 2008 9:55 AM, chris rapier <[EMAIL PROTECTED]> wrote: > dhiggs wrote: > > If someone can split SSH into multiple threads, it should be just as > > possible to split it into multiple processes. However, I expect that > > most high-speed SSH traffic is SCP-/SFTP-based and therefore largely > > I/O bound, so it hasn't been high on anyone's requirements list. > > Based on my experience on working in the field of bulk data transfers on > high speed networks for the past 6 years I'd have to say that you are, > at the least, partly mistaken. However, maybe I'm not really > understanding what you are saying. Could you expand on this a bit more?
Your experience vastly trumps mine, but I'll try to explain my thought processes: What is SSH used for? My initial breakdown was into two categories - shell/batch commands and SCP/SFTP file transport. I guessed that an application that outputs data to stdout at a rate of 10s or 100s of Mbit/s over long periods of time would quickly be changed. The output would be redirected into a file or postprocessed in some other fashion to reduce the amount of raw output a user would have to sort through. This left bulk file transfer as the primary source of SSH traffic. In retrospect I competely overlooked several very important facts. Modern disks have more than enough throughput to saturate gigabit connections - I have NO idea where my "I/O bound" statement came from. Also, SSH encrypted transport can be used for more than just 'put' and 'get'. There are probably more reasons why I'm misguided, but this is enough for now. I apologize and retract that portion of my post; you can safely disregard it as complete lunacy on my behalf. --david
