Brian
At 11:04 AM 12/15/97 -0800, Greg Shue wrote:
>
>"See my comments below..." :-)
>
>-- Greg S.
>
>> See my comments below...
>>
>> Randy
>>
>> > -----Original Message-----
>> > From: Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
>> > 1. Login/Logout
>> >
>> > Some consumer operating systems invoke "login" at boot time, and never
>> >
>> > logout
>> > until shut down. This scheme was designed intended to support SBP-2
>> > HDD as
>> > a boot device. However this scheme is not smart to support PWG
>> > printer.
>> [Turner, Randy] I agree, automatic login at boot time should
>> not be
>> required to support printing. But plug'n play may require this
>> feature,
>> and its not clear whether or not this causes a problem yet for
>> 1284.4
>> printing.
>
>A similar issue may still exist:
>
> Does PnP of 1284.4 devices automatically open a channel at
> boot time to all the services found?
[Brian] We don't want PnP to "bring-up" the I/O stack, except where
required to enumerate the devices, functions, services and the I/O stack
itself. Once enumeration is complete, all I/O connections should be
closed. Later, when the first application requests access to a service,
the appropriate I/O stack is loaded and a connection is established to the
device. When all applications requesting access to services have
"completed" their work (whatever that means), the connections are closed.
We cannot allow PCs to dominate access to devices in the interconnected
world of 1394.
>No matter what, we need to define the policy and behavior of the
>initiator when more initiators are trying to interact with our device
>than the our device has resources to support.
>
> Exactly which initiators don't get access to the device?
> Does this policy give the customer a predictable mapping?
[Brian]The simplest way to implement this is as a FIFO. Whoever asks first
gets access. Note that the device MUST be released when the initiator has
finished using it.
>> > May be, "login" and "logout" shall be associated with DL_register and
>> > DL_unrgister.
>> > Thus I feel PWG-profile shall specify the timing for login/logout.
>> > These facilities
>> > ought to be implemented in Data Link stuff
>> > (DL_register/DL_unregister).
>> [Turner, Randy] I like this idea. The DL_register and
>> DL_unregister
>> entry points for the 1394-based DL would translate these calls
>> into login and logout calls. It seems to make sense for how
>> these
>> entry points were originally designed to work.
>
>So how does this fit in with "transient cable disruptions"
>which last more than 1 second? What takes care of the disruptions?
[Brian} The data link should hide all disruptions that we wish to make
transparent. The transport should be notified when the link is disrupted
for a longer time.
>> > 2. Login waiting time
>> >
>> > IEEE 1394 provides network-like platform for PCs.
>> >
>> > - PC A is printing a document using Printer X.
>> > - PC B is waiting to start printing while 10 seconds.
>> > - PC C is waiting to start printing while 10 minutes.
>> >
>> > Then PC C shall be allowed to start printing session earlier than PC
>> > B.
>> > I felt current PWG protocol stack does not provide any answer to solve
>> >
>> > this issue.
>> > Because PC B or PC C may invoke login while PC A is printing. When PC
>> > A
>> > is printing, the data channel shall be busy, so IEEE 1284.4 transport
>> > replies busy
>> > status if PC B or PC C try to open this channel. But after PC A closed
>> >
>> > this
>> > data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel
>> > earlier than
>> > other PC to open this data channel.
>
>> [Turner, Randy] The description of this "problem" is really an
>> implementation issue. This scenario says that the 1284.4
>> printer would return "busy" if an OpenChannel was attempted
>> while the printer was printing over a previously opened
>> connection. However, the printer may elect to accept an
>> OpenChannel from as many potential clients as possible,
>> and only accept data from the first connection. The other
>> open channels would be processed in some order, as
>> each printing session completes. The other connections would
>> be flow controlled until the printer is ready to accept
>> data on each channel.
>>
>> Basically, the policy that is used for printing arbitration
>> is not defined by 1284.4. It is defined by the application
>> using the 1284.4 transport. Therefore, I don't think the
>> proposal for an OpenChannel_solicitation is necessary.
>> If this type of functionality is needed, it would be an
>> application function, not a transport function.
>>
>> Randy
>
>Randy's reasoning sounds good. The more I think about it, though,
>the more I think the device sharing solution goes beyond our control.
>PC A may have 10 more jobs in it's spooler that are 3 hours old, and
>PC C's job may be only 10 minutes old. We don't have enough knowledge
>to make a completely fair choice from the users' perspective.
>
>The application can determine policy for arbitrating between all the
>requests it can maintain at once, but we have to define (or acknowledge)
>what happens when it the application refuses additional requests.
[Brian] I also like Randy's idea. Our transport needs to be symmetric,
therefore it must have facilities that allow the server to switch between
clients. How it decides to switch between them may be an implementation
issue or we may have to standardize some of it. Isn't there a model in the
network world for this? Shouldn't we look at that model?
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