MultiSwitch, the First USB Sharing Hub
Iddo Genuth writes "A new extension to USB that will enable sharing of various USB peripherals between computers will be available early in 2007. The new MultiSwitch hub technology, developed by SMSC, allows the sharing of information and content from devices such as DVD players, cameras, printers, and scanners, and between laptops and desktops using a simple USB cable. Future hubs may also allow wireless sharing of peripherals."
I remember a linux kernel module which would forward USB packets across the network to another machine which could access them like a virtual USB interface. It was kinda buggy and I don't think it ever made it into the main linux kernel, but it was a neat trick regardless, the guy who developed it told me he developed it after he was laid off and looking for work, but he got a job pretty quickly and stopped working on it.
Finally no more complicated CUPS setups for my printer!
that cost me $14 at the time and supports switching to 4 different hosts?
There are both software and hardware solutions that do similar things already.
(Disclaimer: I am not affiliated with either company, but have used some of both company's techonology at work.)
You are reading a copy of my copyrighted post.
Every time I see technology like this come out it makes me wonder how far we are a way from Maximum Overdrive or Runaway. With communication possible between your toaster, your Roomba, and your computer who knows what will happen if programming goes awry, or worse yet, a virus. Having your computer hooked to a network or the internet makes the concept even more interesting. How long before Fastjack taps into your home network and watches you and your wife on your security cameras? The possibilities of use and misuse are staggering. It's a brave new world out there, Timmy.
There are many tongues to talk, and but few heads to think. -Victor Hugo
Hello blatant product advertisement!
This is NOT "extension to USB"! - this is a proprietary technology that has nothing to do with the USB standard.
USB devices were never meant to be shared this way. Just because someone made 'a switch' that manages to reproduce and route the data between two different host machines at the hardware level doesn't solve anything. You will still have a hopeless guagmire of compatibility issues due to conflicting host software and drivers. Its hopeless because USB devices and software were never meant to work this way. Just because they show it works occationally on one or two devices, doesn't mean it'l work on your devices and with your software for them.
Told you so! Haha!
www.tribalnetworks.org - helping tribal people around the world to own their own means of high-tech communications
Sometimes I wonder, and this "multiswitch" idea just brings home the point, why we have USB and Firewire when it seems like it would be just as effective, and more standardized, for every device to just have built-in gigabit ethernet chips that can communicate using UDP or something.
Protocol? Why not USB over ethernet? Or use OpenSoundControl! _anything_ standardized... Think how much easier that would make it to write drivers. The point is that we can easily separate the protocol from the physical layer, or even from the transport layer. And yet we still have very specific protocols for USB and Firewire technology that are tied to the hardware they run on. It makes little sense to me.
It just seems silly to have all these communication standards that are basically just reinventing the IP protocol. IP has been "plug and play" for like a decade before USB was invented. At the time, of course, it was necessary to have something that could transfer data at certain rates that were unachievable otherwise, but now that most new computers have on-board gigabit ethernet, maybe it's time we took advantage of it. The nice thing about sticking to STANDARDS is that the next time they upgrade the ethernet hardware (10 Gb onboard, for example), device communication would automatically be upgraded with it. As a bonus, backwards compatibility would be easily assured.
Meanwhile, let's improve those damn ethernet connectors already. Goddamn tabs always breaking off...
I know the plastic tabs are a cost-effective solution, but I think we could do better, I honestly do.
It's called FireWire aka iLink aka IEEE 1394.
It's been out for years, it's a mature technology, it actually does support true sharing insofar as the devices can, and it doesn't require a host system. Add into that higher speeds with substantially less overhead (USB is dependent on your CPU) and it sure beats out the it's-USB-with-our-own-wonky-'extensions' stuff.
The downsides are a slightly higher hardware price due to a more sophisticated chipset and a bit of licensing fees (US$.25/device). And of course FW/1394 isn't as universal as USB, though whatever you're looking for is almost always available from somewhere.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Actually I use synergy to do this all the time. (Between Windows & Linux no less.)
It's useful when you have a laptop and a desktop workstation, like I do in my lab at school.
The currently selected computer for keyboard, video, and mouse on my KVM gets to use the USB devices, too. Call it a KVMU switch if you like. I call it Natalie. :-\
It's made by Zonet, or at least sold under that brand name. It's called the KVM3204 and it seems it is already discontinued.
It's one of their PS/2-to-USB KVMs, which lets me use a PS/2 keyboard and mouse with my USB-capable PCs and Macs. My Windows XP box, Mandriva box, and Xandros box even let me use a USB keyboard through the KVM's USB hub. The Mac (PowerMac G4) will use the USB keyboard through the KVM if the machine's booted with the KVM pointed to it and sometimes for the first few switches back and forth. Ironically, though, I have to use a PS/2 keyboard with this switch to get it work work reliably with my Mac.
So, I guess, damn the standards and full steam ahead with the product, or something. It works really well with a PS/2 scroll mouse and my favorite PS/2 keyboard on all my systems.
Check out an MFC with ethernet. I've used two (a cheap HP MFC at work, and a more expensive Brother MFC at home).
In both cases, its real easy to scan a document over the network. I think the HP one lets you scan right from a webpage on the device. The brother may have required proprietary software, but I haven't done it enough to remember.
Either way, this tech is here now. Of course, you have to get a Multi-Function Copier to do it, but if all you care about it the scanner, then perhaps you can get a cheap ink-jet, without worrying about the consumables, since you aren't going to be replacing them.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
FireWire almost has peripheral sharing right, but not quite.
Firewire has a built in allocation scheme for bandwidth, and a scheme to decide who runs the network (yes, there is a node in charge), but it doesn't have an allocation or locking system to decide which hosts are supposed to be talking to which devices. Some per-device hack may be developed to fix that, but if you create a FireWire net with two hosts and two slave devices, there's currently no system to keep both hosts from talking to the same slave device.
FireWire, incidentally, is really a local area network down at the packet level. Calling it a "bus" is marketing-speak. There are packets with source and destination, acknowledges, retransmits, multicast modes, and roughly the same machinery as Ethernet. Yes, there's support for loads and stores into remote addresses in the protocol, but in practice, that means some host generates "store xxx into device register yyy", and out in the peripheral, some embedded CPU executes a switch statement and reaches the "turn camera on" code. The load/store mode lets you send only 32 bits per packet, so major data transfers aren't done that way. It would have been simpler if the thing just had a command/response protocol, like SCSI, and in fact, there's SCSI over FireWire.