I have been quietly monitoring this discussion on the reflector. So far
this is the best analysis I have read.
I agree with Brian almost entirely.. When preparing a standard we must
look into the future. We could be accommodating but we should never be
constricting for the sake of backward compatibility.
Best Regards
Ozay Oktay
Canon Information Systems
----------
From: Brian Batchelder [SMTP:brianb at vcd.hp.com]
Sent: Tuesday, February 17, 1998 12:30 AM
To: p1394 at pwg.org
Subject: Re: P1394> Rough SBP-2 & IP1394 core component ROM
sizes
Time to put in my $0.02-worth. I apologize if any of this is
redundant. I
wrote it a few days ago, but only now have been able to send it.
1394 was designed for, and will be used as a symmetric,
peer-to-peer bus.
The majority of devices will benefit from being able to
communicate with
every other device, which includes both initiating that
communication and
sending and receiving data. Other devices that don't need
peer-to-peer
functionality will also move to 1394 for other factors, e.g.
throughput,
installed base, etc.
IMHO, SBP-2 was designed to provide for those non peer-to-peer
devices by
emulating old master-slave busses on top of this inherently
peer-to-peer
bus. (Flame away!) This works well for mass storage devices,
for example.
The initiator always initiates (sorry) communication. The
target never
initiates communication. The initiator knows the sequence and
quantity of
data to be transferred. The target paces and executes the
transfer of that
data.
Unfortunately, this doesn't map well to true "peers". As I
indicated
earlier, each peer wants to initiate communication with other
peers, in
addition to being the target of other peers. You can think of
this from
the application point of view. Applications that operate as
clients want
to initiate communication with applications that operate as
servers. Most
devices will have both types of applications. Printers have
print engines
(servers) and status engines (clients). Scanners have control
engines
(servers) and scan engines (clients). Multi-function
peripherals have all
of that plus maybe FAX engines, which might act as servers and
clients.
In the past, we have made clients look like servers and
vice-versa, because
of the limitation of our busses. Fine. I can see SBP-2 as a
mechanism to
bring those old implementations to 1394. We have also figured
out ways to
allow clients and servers over master/slave busses by hiding the
"master/slaveness" in the transport layer (1284.4 is an example
of this).
To make SBP-2 work AS IS for us, we would have to choose one of
those two
paths, and we still have to add some other functionality.
Actually, I am currently leaning towards SBP-2, but we must use
it in a way
that allows clients to be clients, servers to be servers, and
both to exist
on every device. This probably means implementing both target
and
initiator (targiator) functionality on each device. If the chip
implementations available today don't optimally support
targiators, well,
we won't be optimal until they are fixed. However, I was
pleased to read
Michael Teener's message in which he indicated that targiators
should be
quite possible.
If, however, targiators CAN'T be supported, I believe we will
have to look
elsewhere for a solution. I like Ats' idea of 1284.4 over
something else
(DFA?). I agree that 1284.4+SBP-2 does feel quite redundant. I
know that
we chose SBP-2 largely because it was an existing standard with
support
from both Microsoft and the mass-storage industry. One thing
this long
discussion has DEFINITELY taught me is that SBP-2 is not
unanimously
believed to be the obvious solution.
Remember, we are specifying a protocol that we must assume will
be used for
at least the next 10 years. Can we afford to limit the
functionality of
our implementations?
Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder | Hewlett-Packard |
mailto:brianb at vcd.hp.com
Connectivity Futurist | 1115 SE 164th Ave. | Phone: (360)
212-4107
DeskJet Printers | Vancouver, WA 98684 | Fax: (360)
212-4227