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@vcd.hp.com
Connectivity Futurist | 1115 SE 164th Ave. | Phone: (360) 212-4107
DeskJet Printers | Vancouver, WA 98684 | Fax: (360) 212-4227