Thursday, March 20, 2008

Routed

I'm thinking of doing a hardware upgrade to our home network, and I'm looking for ideas.

We have a router that's hardwired to our desktop PC (what might be fairly called our aging desktop PC). It's a wireless router, and our three laptops - the new one, the old one thats essentially got Alzheimer's, and my wife's work PC - talk wirelessly to it, and from thence to the Interweb. We've also got two printers, both of which are hard wired into the desktop PC. One's plugged in with a USB cable; one with a parallel cable. Finally, we have an external hard drive, which isn't really hardwired into anything; it sits on the desk where the desktop PC resides, and if I want to use it, I plug it into a USB jack; ditto for when I want to transfer backups from the laptop.

What we want to do is change the way things are configured. Specifically, we want to be able to get to the printer(s) without having to have the desktop PC on, and I want to be able to get to the external hard drive without having to schlep over and plug in the jack. Such a bother. I know that I can get a wireless router into which the USB printer can plug. I don't know if I can get one into which I can also plug the external hard drive, let alone the parallel printer. Finally, if we do this, I would like to use the existing router for something useful. I seem to recall reading once that routers can be used as repeaters, to extend the range of the 'base' router, but I'm not sure about that.

Any thoughts?

4 comments:

Unknown said...

First things first: routers can be used as repeaters, but they're just not very good at it.

I don't know of any PC-oriented systems like Apple's Time Capsule product.

Wireless thingies for the printer - no problem, for a hard-drive? I'm not sure. Of course, one way of finding out if it works - is get a printer WiFi-USB box and plug the hard drive into it, and see if Windows can figure out what to do next. I doubt it will be able to (no, not because it's Windows), because the drivers won't know what to do with that particular configuration.

The basic problem is that Windows, the USB driver sits at the same architectural "level" as the disk drivers. And there's no built-in way for the two to communicate. Unix is different; it handles all input and output as streams of bits - so feeding the output of one stream into another bit of code is almost trivial. Windows handles it all "a bit different"...

Take a look at PC Magazine, and Tom's Hardware - if a solution exists, it'll be published in one of those. Personally, I'd stay away from the 'hacks' - these might get you working, but my experience with such things leads me to suspect that they'll take more time being maintained than I want to give! (Was that a polite way of saying "they tend to be really unreliable"? :-) )

Sorry!

Carolyn Ann

Cerulean Bill said...

Hmm... I'm not very much into the concept of architectural levels for PCs, but the concept makes sense to me, for an odd reason -- it reminds me of when I studied SNA networking protocols, and the whole idea of hardware layers and message encapsulation. On one hand, I can't see why it wouldn't work - after all, its 'just' a USB connection -- but I guess I don't want to rely on that.

Tom's Hardware, huh? I'll take a look. Thanks.

Unknown said...

Funny story - I was trying to explain the SNA protocols to some guy who'd basically apprenticed himself to me. I was getting nowhere - literally nothing about the protocol stack was making sense to Joe - until I explained how IBM was structured when they built SNA. :-)

No ding on IBM - it was a good protocol. But you really did have to know the context to understand it!

Yeah, on the USB thing - but the way Windows is structures, it doesn't allow interprocess communication at that level; so the bit that calculates the disk can't talk to the bit that figures out the USB protocol.

The thing about it that most driver communication happens at Ring 0 on the chip; the CPU has a number of "rings", which correspond to different capabilities. Ring 0 (zero) is the uber-ring, and it's partly why Windows can get into so much trouble with virii. Vista and XP are slightly different, but as MS isn't telling anyone what Vista does, and XP is based on code from NT - I can only assume they're either radically different (likely) or almost the same (not that likely, considering the problems people are having writing drivers for Vista!)

Basically, Windows does thing in an arcane manner that makes sense when you look at the overall architecture of MS Windows. And when you think about the corporate structure, and goals, of Microsoft. So your SNA analogy is a little too close - eerily close, I might add! :-)

Anyway, no matter what people might say about Windows, it works - and it works quite well. Just like the IBM SNA architecture! (The worst protocol I've ever come across was an old DEC one; it reversed the system address, making it pseudo-little-endian; it was actually stored in a sequential format, but the protocol designer - who later issued an apology for it! - decided it made sense to put the address into a lower-order first sequence. If memory serves, it was to make local network routing slightly easier. What a nightmare! It was definitely as bad as my description!)

Carolyn Ann

Cerulean Bill said...

Sounds right up there with bare-metal coding, which was before my time and beyond my skills....