Back to the main page

Mailing List Logs for ShadowRN

From: Alfredo B Alves <dghost@****.COM>
Subject: Re: Fiber optics
Date: Thu, 14 May 1998 12:07:36 -0500
>At 01:30 AM 5/14/98 -0500, D.Ghost wrote:
>>How about this ... the lines are fiber optical right? Normally fiber
>>optics have lasers and receptors at both ends so unidirectional lines
>>only have lasers on one end and receptors on the other ... sound good?
>>Or was there some mechanics quirk? I can't remember, my copy of NAGRL
is
>>with a friend ...

On Thu, 14 May 1998 11:18:59 -0400 Paul Gettle <pgettle@********.NET>
writes:
>IIRC the unidirectional datalines were a special formulation of fiber
>optic, that would only let the light through in one direction. Your
>method sounds a lot cheaper though.

Ok...It's coming back to me now ... (BTW, I don't know why "hardwired"
uni-directional lines would be designed any other way ... perhaps the
author of NAGRL wasn't too familiar with fiber optics? [I just looked em
up in my on-line encyclopedia and figured out how to make em
uni-directional...])

<SNIP Matrix Explanation>
>Then, the concept of one-way datalines between nodes is introduced.
>The idea is that data can only flow one way. The text describes the
>deckers personas being able to use these datalines like regular
>datalines, but there's a problem. If the data can only go one way, the
>instant the decker sends his persona program down the one-way line,
>the data from the persona's sensors will be cut off. The dataline is
>one-way, and the communication from persona to deck can't travel back
>up the pipe. The deck would have no information to construct simsense
>from. The decker can still send commands to the persona, but he'd be
>decking blind.
>
>One-way datalines would have been a wonderful concept, if deckers
>weren't allowed to go down them. Deckers could always cause havoc with
>autonomous program-frames sent down the one-way pipe, after all. As
>is, though, the concept is difficult to merge with the previous
>information about the matrix.
>
<SNIP Sig>
> -- Paul Gettle (pgettle@********.net)
<SNIP More Sig>

OK. You could 1) say the uni-directional status is really a software
enforced psuedo uni-directional thing (ie the line itself goes both ways
but there are MUCH fewer authorized transmissions going one way than
going the other ...) or 2) say that deckers can't go down uni-directional
lines.

Option 2 is fairly straightforward and I can't think of any additional
points that need to be made ... :)

Option 1 would make it tougher for deckers to deck through
uni-directional datatlines but not impossible ... (ie give a bonus to any
IC or a penalty to the decker's utilities ...) also with less authorized
access the IC could be able to more thoroughly check the incoming ("Wrong
Way") data (ie they'd have MUCH more info on what is allowed ... also the
traffic would probably be fairly low and regular (not neccessarily
steady, just fairly predictable) and so if suddenly a decker started
using this line to send his simsense channel down, it would set off all
sorts of alarms (data he could send bits at a time but that could take a
long time) If this is done with a second uni-directional line, the
second could even have a much lower bandwidth ...

Both variations would most likely exist depending on the needs of the
owners of the computer system ...

Here's a nifty thought for security:
You have a Host that is connected to the Matrix through two
uni-directional lines but then connections on-site are bi-directional ...
a decker hacking in from the Matrix would go in one Uni-dir line and have
his feeds etc... come out the other ... while corp security deckers would
use the on-site bi-dir lines ... what kind of advantage would the corp
decker have over the matrix decker?

Querry: How many copies of one frame can a decker have running around the
matrix at once?

D.Ghost
(aka Pixel, Tantrum)

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.