Greg,
Thank you for your effort to make the comparison table.
I agree that DPP has similar functions with SBP2 if you use two SBP2s
with cross-logins.
I guess the reason you need two SBP2s for single print task and DPP
needs only one comes from the differences of the models.
Because SBP2 is host-target model, you needs two logins for one peer to
peer connection.
I don't say DPP is more suitable to any tasks or any printing tasks. I
just want to say DPP is being defined for Peer to Peer printing.
Also I prefer one application uses only one session. Of course some task
requires more than one session but at least for very simple print task
or file transfer task, I prefer small number of sessions.
model 1)
---------------
| Application | This is better for consumer products than model 2.
----------------
| One Protocol |
| or One session|
----------------
model 2)
------------------
| Application |
------------------
| more protocols |
| or more sessions|
------------------
Again I don't want compete with SBP2. SBP2 has more functions like ORB and natural flow control.
We are developing DPP and THIN protocol. The biggest priority for THIN
protocol is the size and simplicity. I cannot explain the reason we
need two logins for simple print task to our product engineers. Also I
cannot explain the reason we need 20 or 30KB for print protocol, while
the file transfer protocol using IR(Infra-Red) communication (called Ir
TranP) needs only several Kilo bytes.
Toru Ueda
Sharp Corp.
Software Labs.
On Fri, 20 Feb 1998 16:46:07 -0800 (PST)
Greg Shue <gregs at sdd.hp.com> wrote:
>> Hi all,
>> The more I look at DPP 0.71, the more similar it looks
> to SBP-2. So, I put together a concept "cheat sheet"
> to see how the two really compared. I thought you
> might be interrested, so here it is... What do you think?
>> - Greg Shue
>> ===============================
> SBP-2 vs. DPP v0.71 Cheat Sheet
> ===============================
>> There are many similar concepts between SBP-2 and DPP v0.71 which
> may not be well understood. The main difference between the
> protocols revolves around the a/symmetry of the protocol stacks.
> This "cheat sheet" is intended on laying the groundwork for a
> direct comparison of the protocol stacks.
>>> SBP-2 Model of Use for Comparison
> ---------------------------------
> In order to get a reasonable comparison of the protocols, then
> a Command Set and Model-of-use must be outlined for SBP-2. Many
> of the details can be left out of the outline as long as the
> essence of the profile is maintained.
>> Model of Use
> ------------
>> - cross-logins are established between the two devices.
> (This avoids a merged target/initiator driver)
>> - each device provides a fetch engine and a task list.
>> - each task list contains commands to transfer data in one direction
> (we'll choose it such that only WRITE transactions occur for
> moving the ORB data block)
>> - each ORB allows one "data unit" to be processed.
>> Command Set Provides For
> ------------------------
> - cross-login information
> - negotiated max data block size per task per direction.
> - indicating byte-size of completed packet
> - carrying of Command IDs in CDB (2 bytes)
> - carry "SDU segmentation number" in CDB (4 bytes)
> - carry "SDU end of segment flag" in CDB (1 bit)
> - carry routing info in CDB (2 byte Dest PID, 2 bytes Src PID)
>>> Cheat Sheet
> ===========
>> CSR structures Thin Protocol SBP-2
> -----------------------------------------------------------------------
> Access Control i/f Connection Reg Mgmt Agent Reg
>> Response Space SDU Response Space Fetch Agent Regs
>> Completion status SDU Control Space Status FIFO
>> Transfer block SDU Register data block referenced by ORB
>>> Functional layers Thin Protocol SBP-2
> -----------------------------------------------------------------------
> Connection mgmt Thin Session Management Agent
>> Data Transfer eng Thin Transaction Fetch Agent
>>> Session Mgmt Thin Protocol SBP-2
> -----------------------------------------------------------------------
> Access Request S_Connect login
>> Reconnect T_Reconnect reconnect
>> Execute App Cmd S_Command ORB exists on task list
>> Access Release S_Disconnect logout
>> Error Notification <none> Mgmt-ORB specified Status FIFO
> completion notification
>>> Data Transfer Thin Protocol SBP-2
> -----------------------------------------------------------------------
> Transfer Space SDUAck ORB exists on task list
> Available (write implies avail) (existance implies available)
>> Transfer completion SDUComp Notification write to
> notification Status FIFO
>> Transfer Abort from SDUStop Abort Task (Set)
> data receiver
>> Transfer Abort from SDUStop Notification write to implicit
> data sender Status FIFO - Abort
>> Error Notification T_error Notification write to implicit
> Status FIFO - error ind.
>>> Feature Comparison
> ==================
>> Feature Thin Protocol SBP-2
> -----------------------------------------------------------------------
> Each node can send/rcv Yes Yes
> data
>> Dynamically allocates Yes Yes
> CSR Reg space when
> estab. connect
>> Selectable Transfer Yes Yes, requires Create Stream
> Mode request and separate
> task list
>> Symmetric Structure Yes Yes
>> Negotiated Data Unit Yes Yes
> size independently
> per direction
>> Isochronous Support Yes Yes
>> Multiple Cmd Support Yes Yes
>> Bidirectional Cmds Yes Yes
>> Multiple Independent Unspecified (possible Yes, via Multiple LUNs &
> Connection Support w/ multiple UNIT Dirs) multiple UNITS
>> Session segmentation Yes Yes, in CDB
> support
>>> Distinctive differences:
>> Feature Thin Protocol SBP-2 w/ proposed profile
> -----------------------------------------------------------------------
> Reconnect Support 2 sec window; 1 sec window, proposal made
> either end may for programmable extension;
> establish both ends must reestablish
>> SDU Available SDU Ack timeout exists None (?)
> timeout Does this imply a real-
> time processing req. on
> whatever data is sent
> in an SDU?
>> Connection Process 2 block writes 6 block writes (probably)
> (2 logins @ 2 per login,
> 2 for negotiated params)
>> Shared memory buffer Fixed location during Relocatable, partitionable
> connection
>> Data Transfer more efficient for More flexible and standardized
> data < MTU size
>> data < MTU size SDUAck + WR Agent Reset + WR ORB ptr +
> SDUComp + ORB prefetch + data xfer +
> SDUAck Completion Notify
> (3 transactions vs. 5 transactions)
>> MTU size << data < SDUSend + WR Agent Reset + WR ORB ptr +
> SDU size SDUComp + ORB prefetch + page table +
> data xfer +
> SDUAck Completion Notify
> (SBP-2 costs 3 extra transactions,
> but a small overhead
>> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs at sdd.hp.com> ----------------------------------------------------------------
>