Slashdot Mirror
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."
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.
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
If you had bothered to read the fine article, you would realize that four machines can't use the USB device at the same time with this, either.
From the article:
The opposite of progress is congress
From TFA:
Q: What happens when two people try to use the same device at the same time from two different computers?
A: Keep in mind that USB provides a connecting technology and not a network. Since the USB MultiSwitch Hub is a standard USB 2.0 device, only one person can use a connected device at a time. For example, I plug in my MultiSwitch Hub-enabled laptop, share your printer and/or get what I need from an external USB hard drive and then, when you want it back, we switch the devices back to you. If we want to toggle back and forth, we can do that. But only one of us can access the desired USB device at a time.
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.
Only difference is that you can switch per device on this thing.
No Comment.
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.