> > ??? > > Please explain a bit more about exactly what you're trying to accomplish... > > Large medical images -- some approaching gigabyte sizes. > > The internal network connects multiple facilities. The images may need > to be shared across multiple facilities. > > Our preferred solution is to put one (1) copy of each image on a large > and robust fileserver inside their network. The catch is, they are > using proprietary systems for viewing and analyzing the images and we > may not be granted access nor information adequate to implementing our > preferred solution. Currently, the remote sources are using their > proprietary systems (black boxes) to auto-magically transfer the files > directly to one (1) proprietary system inside our customer's network. > Yes, this looks everyway like ftp -- except the proprietary system > vendor says, no, it is not that simple ;> > > When one of these images is needed on another proprietary system inside > this network, somebody needs to push the required file to another > proprietary system. Our customer wants ``pull'' access from any given > system. > > In brainstorming alternatives, this occured to me: > > send images > | > V > internet > | > V > firewall > | > --------------------- > | | | > V V V > host_1 host_2 host_n ... > > Regardless, whether or not this is the best solution for this > application, how can this be done?
Well, it sounds like you're in black-box hell :< My current understanding of your problem (please correct me if I'm wrong): - A remote, black-box system pushes images to one black-box system in your customer's network (let's call it "Master") - Your customer can push images from the Master black box system to several other black-box systems (Slaves) - Your customer wants to be able to view images from any slave system w/o having to push the file from the master system (ie pull, not push) Without an understanding of the black-boxes involved, there's not a lot you can do here. If I am now understanding your initial question properly, you are asking if it's possible to somehow get the remote system to push the image content to multiple systems on your internal network. The simple answer is no...there is no straight-forward network slight-of-hand that will allow you to trick one system into talking multiple remote systems at the same time. The more complex answer is maybe, and depends a lot on unknown details of your black-box systems... I can think of a few things that could potentially help you: 1) Get the remote system to push the data to all clients. This will chew up lots of internet bandwidth, and will either require multiple external IP's, or control over which ports are used to connect (assuming you're running a masqueraded internal network). 2) Get the Master internal system to push the data to all slave systems. This may be possible to automate, or it may require a "console jocky"...depends on unknown (to me) details of your black-box systems. 3) Whip up a Black-Box emulator, that can talk the file-transfer protocol used by your systems. Have your remote system transfer files to your fake system, then push the data from there to all internal systems, as required. This will require network programming (not too tough in modern languages like Java, Perl, Python, &c) and an understanding (or reverse engineering) of the file transfer protocols used by your equipment. 4) Read through the docs for your black-boxes, and see if they support any kind of image-server access. I think this is really what you want...a central image server. If you're lucky, you can do this with a *nix box. If you're unlucky, you'll need a propriatery box from your vendor for the other systems. If you're really-really unlucky, there's no support for any kind of 'pull' technology on the individual Slave stations. NOTE that everything but the last option requires lots of storage capacity on each image station, since each station is storing copies of all the image files. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
