Storage Commitment question
Arkady Gliner
I am trying to design Storage Commitment push model SCU. The DICOM
standard clearly separates Storage and Storage Commitment. Which
implies that the address mapping (IP + port + AE title) can be
different for Storage SCP and Storage Commitment SCP.
My question is this: would it be a reasonable assumption that
in real world the address mapping mapping for Storage SCP and
Storage Commitment SCP would be the same for both?
Arkady
ark...@tamri.com
Dee Csipo
Do not make the assumption that the EA where you store the images is the AE
where you have to commit them. Also make sure that your SCU supports the
required acceptance of the connection initiated by the SCP with reverse role
negotiation.
dee
;-D
Arkady Gliner
>Arkady,
>
>Do not make the assumption that the EA where you store the images is the AE
> where you have to commit them. Also make sure that your SCU supports the
> required acceptance of the connection initiated by the SCP with reverse role
> negotiation.
This is a good point. And this is another item I am not sure about -
how do I know that the SCP wants to use different association
for N-EVENT-REPORT? Here is the scenario:
open association
send N-ACTION request for Storage Commitment
receive N-ACTION response status
This is where I am not clear. The standard says that "action taken by
the SCU upon receiving the status is beyond the scope of this Standard."
The obvious choices seem to be:
1. Always close the association and let SCP open one for N-EVENT-REPORT.
Should this be acceptable for all SCPs? Or is it reasonable to expect
that some SCPs can only respond on the original association?
2. Assume that if SCP wants to report on a different association it
will close this one so SCU can simply wait for either N-EVENT-REPORT
or for association to be closed by SCP. Or is this a bad assumption?
Or am I missing something here?
Arkady
ark...@tamri.com
Dee Csipo
Arkady Gliner wrote:
> Dee Csipo wrote:
> >Arkady,
> >
> >Do not make the assumption that the EA where you store the images is the AE
> > where you have to commit them. Also make sure that your SCU supports the
> > required acceptance of the connection initiated by the SCP with reverse role
> > negotiation.
>
> This is a good point. And this is another item I am not sure about -
> how do I know that the SCP wants to use different association
> for N-EVENT-REPORT? Here is the scenario:
>
You do not know. It is both an implementation and a timing issue.
1. (Odjin) You as an SCU how do you know how long you need to keep the
association open. My SCP may want to go out and have a good time with them shiny
platters, before it wants to even recognize your existence:-).
2 (Dwa) A more legitimate use might be, where the storage commitment
N-EVENT-REPORTS are in response to some media that the guy drug in three days
later. There are legitimate teleradiology applications where there is no
bandwidth or reliable connection to get the images to a destination. A storage
commit request may indicate that someone will carry the image in one day.
> open association
> send N-ACTION request for Storage Commitment
> receive N-ACTION response status
>
> This is where I am not clear. The standard says that "action taken by
> the SCU upon receiving the status is beyond the scope of this Standard."
> The obvious choices seem to be:
>
> 1. Always close the association and let SCP open one for N-EVENT-REPORT.
> Should this be acceptable for all SCPs? Or is it reasonable to expect
> that some SCPs can only respond on the original association?
Very reasonable solution indeed. The SCP SHALL be prepared to open an association
anyway, because the SCU behavior is not specified. But the text i think refers to
the internal implementation specific reaction of the SCU to the N-EVENT-REPORTS.
If you could point out the section it might clear up some of the confusion on my
end.
>
>
> 2. Assume that if SCP wants to report on a different association it
> will close this one so SCU can simply wait for either N-EVENT-REPORT
> or for association to be closed by SCP. Or is this a bad assumption?
>
Very bad. The SCP shall never close an association opened by an SCU. The only
exception is an ABORT in response to a protocol violation.
David Clunie
> Dee Csipo <dcs...@charm.net> writes:
> > Also make sure that your SCU supports the
> > required acceptance of the connection initiated by the SCP with reverse role
> > negotiation.
>
> and connect to a modality in the middle of an examination, just to see
> if they might be interested in commitment?
Dee is talking about the fact that the N-EVENT-REPORT may come
on a different association than the one the N-ACTION request
was sent on, and that it may have been initiated by the SCP.
Specifically:
1. The SCU sends an N-ACTION on an association, and then closes
the association before an N-EVENT-REPORT is received (or
the SCU drops it or there is a network failure or there is
a race condition between closing the association and handling
the event), which therefore needs to be sent on a different
association.
2. a. The SCP initiates a new association for the purpose of
sending the N-EVENT-REPORT, and after establishing it and
turning it around, send the N-EVENT_REPORT.
- or -
b. The SCU initiates another association with the Storage
Commitment Push SOP Class (possibly amongst others), either
to send images or send another N-ACTION, and gets the
N-EVENT-REPORT back on that association.
To Arkady's comment in the next thread, you have to handle all
possibilities. The SCU can never know which way the SCP is going
to do it.
Specifically, you may not be able to ensure the N-EVENT-REPORT
won't come back on the same association, since the SCP may send
it faster than the SCU can close it. So the SCU must be able to
handle the N-EVENT-REPORT on the same association.
Obviously the SCU also has to be able to handle an inbound
association from the SCP specifically for the N-EVENT-REPORT,
otherwise it may never get it.
Finally the SCU has to be able to handle the N-EVENT-REPORT
if it occurs on another association established for a different
purpose.
Equally from the SCP side, while one can choose to always send
the N-EVENT-REPORT on a different association, one cannot choose
to always send it on the same association since it may get closed
before you have a chance.
Charles has a CP to try to clarify the language on this in the
standard to make it clearer, without changing the definition.
david
--
David A. Clunie mailto:dcl...@idt.net
Director, Medical Imaging Technologies http://idt.net/~dclunie/
Quintiles Intelligent Imaging http://www.i2image.com/
521 Plymouth Rd #115 Work 610-238-0572 Fax -0578
Plymouth Meeting PA 19462 Home 570-897-7123 Fax -5117
harry....@ieee.org
dcl...@idt.net wrote:
> ....
> 1. The SCU sends an N-ACTION on an association, and then closes
> the association before an N-EVENT-REPORT is received (or
> the SCU drops it or there is a network failure or there is
> a race condition between closing the association and handling
> the event), which therefore needs to be sent on a different
> association.
>
> 2. a. The SCP initiates a new association for the purpose of
> sending the N-EVENT-REPORT, and after establishing it and
> turning it around, send the N-EVENT_REPORT.
>
> - or -
>
> b. The SCU initiates another association with the Storage
> Commitment Push SOP Class (possibly amongst others), either
> to send images or send another N-ACTION, and gets the
> N-EVENT-REPORT back on that association.
Let's look at it from the point of view of the SCP implementor. Option
1 is not attractive for exactly that race condition - I don't know if I
can send the N-EVENT_REPORT on the original association, since it is
dependent on the SCU keeping the association open, so I won't waste the
effort to implement this unreliable option. Option 2b has the same
problem. Only Option 2a will be reliable, since the SCP is the
association initiator and is responsible (in the non-abort condition)
for keeping the association open as long as necessary.
Now let's return to the SCU. The SCU does not have any knowledge of how
long the SCP will take to ensure storage and generate an N-EVENT_REPORT.
Therefore, the SCU would need to keep an association open perhaps
indefinitely, and handle re-establishing it after all possible failure
conditions, until the response is returned. Not an appealing prospect.
However, the SCU does not have to implement any of that if it simply
waits for the SCP to open an association for the N-EVENT_REPORT (2a).
From both perspectives, 2a is the most reliable and probably the
simplest to implement.
Harry Solomon
Principal Member of the Engineering Staff
L-3 Communication Systems - East
1 Federal Street
Camden, N.J. 08103
harry....@L-3com.com
+1.856.338.2686
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Hans Buurman
> Specifically:
>
> 1. The SCU sends an N-ACTION on an association, and then closes
> the association before an N-EVENT-REPORT is received (or
> the SCU drops it or there is a network failure or there is
> a race condition between closing the association and handling
> the event), which therefore needs to be sent on a different
> association.
>
> 2. a. The SCP initiates a new association for the purpose of
> sending the N-EVENT-REPORT, and after establishing it and
> turning it around, send the N-EVENT_REPORT.
>
> - or -
>
> b. The SCU initiates another association with the Storage
> Commitment Push SOP Class (possibly amongst others), either
> to send images or send another N-ACTION, and gets the
> N-EVENT-REPORT back on that association.
But CP 153 Final Text says:
3-In Section J.3.3.1.3, SCU behavior add: An SCU shall be capable of
receiving an N-EVENT-REPORT on a different association than the one on
which the N-ACTION operation was performed.
Note: To receive this N-EVENT-REPORT, the SCU accepts an association
where the SCP role is proposed by the Storage Commitment SCP acting as
an association requestor.
(end of quote)
Doesn't this note exclude possibility 2b ? Or should this clarification
be clarified ?
Hans
Arkady Gliner
> > the association before an N-EVENT-REPORT is received (or
> > the SCU drops it or there is a network failure or there is
> > a race condition between closing the association and handling
> > the event), which therefore needs to be sent on a different
> > association.
> >
> > 2. a. The SCP initiates a new association for the purpose of
> > sending the N-EVENT-REPORT, and after establishing it and
> > turning it around, send the N-EVENT_REPORT.
> >
> > - or -
> >
> > b. The SCU initiates another association with the Storage
> > Commitment Push SOP Class (possibly amongst others), either
> > to send images or send another N-ACTION, and gets the
> > N-EVENT-REPORT back on that association.
>
> 1 is not attractive for exactly that race condition - I don't know if I
> can send the N-EVENT_REPORT on the original association, since it is
> dependent on the SCU keeping the association open, so I won't waste the
> effort to implement this unreliable option. Option 2b has the same
> problem. Only Option 2a will be reliable, since the SCP is the
> association initiator and is responsible (in the non-abort condition)
> for keeping the association open as long as necessary.
>
> Now let's return to the SCU. The SCU does not have any knowledge of how
> long the SCP will take to ensure storage and generate an N-EVENT_REPORT.
> Therefore, the SCU would need to keep an association open perhaps
> indefinitely, and handle re-establishing it after all possible failure
> conditions, until the response is returned. Not an appealing prospect.
> However, the SCU does not have to implement any of that if it simply
> waits for the SCP to open an association for the N-EVENT_REPORT (2a).
Note that SCU can not prevent SCP from sending an N-EVENT_REPORT on
this association. Thus SCU must somehow hadle it. The question
is: is it aceptable to handle this by not responding to
N-EVENT_REPORT on this association to force SCP to open
a new association as in 2a?
>
> From both perspectives, 2a is the most reliable and probably the
> simplest to implement.
I think that the simplest model that always works is the best to
implement. Seems to me that
SCU: open association
send N-ACTION request
wait for N-ACTION responce
close association (just close it to avoid race condition)
SCP: do 2a above (may be after trying 2b and failing)
should always work.
Are there scenarios where this would fail?
Arkady
ark...@tamri.com
David Clunie
> But can it afford to wait? If the SCP really is slow, then there's a
> chance that the modality is locked up and unusable. But that may be
> the only option if the modality can't afford the resources to handle
> asynchronous association requests. But if a system can handle an
> association request asynchronously, there is still a possibility
> spiking cpu/disk use in the middle of an examination.
There is no way the modality can hang up waiting for the
response ... it might be seconds, months or years before it
comes, for the legitimate reasons Dee has already mentioned.
You can't play Storage Commitment without being prepared to
accept asynchronous association requests and N-EVENT-REPORTs.
However, compared to handle GUI requests, background archive
and image network queue requests, etc. the overhead involved is
pretty trivial isn't it ? Remember you don't have to deal with
the N-EVENT-REPORT during scan acquisition, just queue it
in memory somewhere, if you don't want to mess with a database
update or whatever during the acquisition.
David Clunie
> Note that SCU can not prevent SCP from sending an N-EVENT_REPORT on
> this association. Thus SCU must somehow handle it. The question
> is: is it acceptable to handle this by not responding to
> N-EVENT_REPORT on this association to force SCP to open
> a new association as in 2a?
I don't think it is acceptable to do this except under true failure
conditions ... a poorly written SCP may never bother to try to send
the N-EVENT-REPORT, and the SCU will be waiting for ever.
Don't assume the other guy is going to do the right thing. Whether you
are the SCU or the SCP, it is your job to handle every contingency properly,
regardless of how ill conceived the standard might seem to you, or what
short cuts seem apparent. The more you get creative here the less
interoperable you will be. This is also a hard service to test
exhaustively, so expect more surprises in the field.
> I think that the simplest model that always works is the best to
> implement. Seems to me that
>
> SCU: open association
> send N-ACTION request
> wait for N-ACTION responce
> close association (just close it to avoid race condition)
>
> SCP: do 2a above (may be after trying 2b and failing)
>
> should always work.
>
> Are there scenarios where this would fail?
You can't "just close an association" to avoid the race condition;
by definition the race condition occurs when the SCU send an
A-RELEASE-RQ while the SCP has sent a P-DATA-TF containing an
N-EVENT-REPORT command. No matter how fast the SCU, is the SCP
may be faster, particularly since the SCU has to wait for the
N-ACTION-RSP P-DATA-TF before sending the A-RELEASE-RQ, and the
SCP may well have put its N-EVENT-REPORT P-DATA-TF on the wire
immediately following the N-ACTION-RSP P-DATA-TF.
Regardless, this should always work, unless the SCP has also
decided to take shortcuts. If the SCU is going to, why shouldn't
the SCP ?
Harry's comment is very appropriate ... the SCP is really the
guy in control here, and the only one that has the option of
picking the cleanest solution. The SCU has to handle all of
the contingencies.
In retrospect one could argue that the N-EVENT-REPORT on a
separate association should have been the only permutation
allowed, but it is too late for that know.
David Clunie
>
> David Clunie wrote:
...
> > b. The SCU initiates another association with the Storage
> > Commitment Push SOP Class (possibly amongst others), either
> > to send images or send another N-ACTION, and gets the
> > N-EVENT-REPORT back on that association.
>
>
> 3-In Section J.3.3.1.3, SCU behavior add: An SCU shall be capable of
> receiving an N-EVENT-REPORT on a different association than the one on
> which the N-ACTION operation was performed.
>
> Note: To receive this N-EVENT-REPORT, the SCU accepts an association
> where the SCP role is proposed by the Storage Commitment SCP acting as
> an association requestor.
>
> (end of quote)
>
> Doesn't this note exclude possibility 2b ? Or should this clarification
> be clarified ?
Hi Hans
It doesn't exclude 2b, it just mandates SCU support for 2a. It says
that an SCU shall be capable of 2a, but doesn't say the SCP can't
send the N-EVENT-REPORT on ANY open association for which the
appropriate SOP Class has been negotiated. The note elaborates on
the 2a scenario but without suggesting that other behavior is not
allowed.
Having said that, yes there is another Storage Commitment CP in the
works, to make everything even more clear :)
David Clunie
>
> David Clunie <dcl...@idt.net> writes:
...
> What about the SCP opening a new association while the original
> storage commitment association is still open?
That is allowed ...one can have as many asssociations open as
one wants.
> > Finally the SCU has to be able to handle the N-EVENT-REPORT
> > if it occurs on another association established for a different
> > purpose.
>
> But only an association in which Storage Commitment was negotiated
> for I assume?
Absolutely.
Arkady Gliner
>
...
>
> You can't "just close an association" to avoid the race condition;
> by definition the race condition occurs when the SCU send an
> A-RELEASE-RQ while the SCP has sent a P-DATA-TF containing an
> N-EVENT-REPORT command. No matter how fast the SCU, is the SCP
> may be faster, particularly since the SCU has to wait for the
> N-ACTION-RSP P-DATA-TF before sending the A-RELEASE-RQ, and the
> SCP may well have put its N-EVENT-REPORT P-DATA-TF on the wire
> immediately following the N-ACTION-RSP P-DATA-TF.
I still do not see a reliable way to avoid the race condition.
SCU sends N-ACTION request, waits and receives N-ACTION-RSP.
It is now done with Storage Commitment request.
SCU may now wait for N-EVENT-REPORT on the same association.
But it can not wait forever. So may be after a timeout SCU
will decide to close the association. If SCP decides to send
N-EVENT-REPORT report at exactly this time SCU is no longer
prepared to handle it.
Seems to me that while SCU can attempt to minimize the
possibility of this happening there is always a window
of opportunity for N-EVENT-REPORT to clash with association
release by SCU.
May be the standard should address this issue?
E.g.: If SCP is unable to send N-EVENT-REPORT on the same
association as N-ACTION request it must be prepared to
open another association.
Arkady
ark...@tamri.com
David Clunie
> May be the standard should address this issue?
> E.g.: If SCP is unable to send N-EVENT-REPORT on the same
> association as N-ACTION request it must be prepared to
> open another association.
That is exactly what the standard says !
Todor Kantchev
Darin Johnson wrote in message ...
>Dee Csipo <dcs...@charm.net> writes:
>
>> Do not make the assumption that the EA where you store the images is the
AE
>> where you have to commit them.
>
>Especially for IHE. (I still can't fathom why two different locations
>for storage and storage commitment would be useful in real life, any
>hints anyone?)
We can have one Image Manager and many (distributed) Archivers, managed by
it.
Modalities send images directly to archivers, allocated to them, while
sending MPPS and SCmt to the Image Manager. This is a PACS architecture we
definitely consider worth doing. It reflects the natural pattern of image
distribution around the hospital departments, is more reliable etc. I think
Philippe has something to say here but he keeps silent.
Tod.
Todor Kantchev
Dee Csipo wrote in message <37B214C3...@charm.net>...
>Hi Arkady,
>
>Arkady Gliner wrote:
>
>> Dee Csipo wrote:
>> >Arkady,
>> >
>> >Do not make the assumption that the EA where you store the images is the
AE
>> > where you have to commit them. Also make sure that your SCU supports
the
>> > required acceptance of the connection initiated by the SCP with reverse
role
>> > negotiation.
>>
>> This is a good point. And this is another item I am not sure about -
>> how do I know that the SCP wants to use different association
>> for N-EVENT-REPORT? Here is the scenario:
>>
>
>You do not know. It is both an implementation and a timing issue.
>
>1. (Odjin) You as an SCU how do you know how long you need to keep the
>association open. My SCP may want to go out and have a good time with them
shiny
>platters, before it wants to even recognize your existence:-).
>2 (Dwa) A more legitimate use might be, where the storage commitment
>N-EVENT-REPORTS are in response to some media that the guy drug in three
days
>later. There are legitimate teleradiology applications where there is no
>bandwidth or reliable connection to get the images to a destination. A
storage
>commit request may indicate that someone will carry the image in one day.
>
>> open association
>> send N-ACTION request for Storage Commitment
>> receive N-ACTION response status
>>
>> This is where I am not clear. The standard says that "action taken by
>> the SCU upon receiving the status is beyond the scope of this Standard."
>> The obvious choices seem to be:
>>
>> 1. Always close the association and let SCP open one for N-EVENT-REPORT.
>> Should this be acceptable for all SCPs? Or is it reasonable to expect
>> that some SCPs can only respond on the original association?
>
>Very reasonable solution indeed. The SCP SHALL be prepared to open an
association
>anyway, because the SCU behavior is not specified. But the text i think
refers to
>the internal implementation specific reaction of the SCU to the
N-EVENT-REPORTS.
>If you could point out the section it might clear up some of the confusion
on my
>end.
>
>>
>>
>> 2. Assume that if SCP wants to report on a different association it
>> will close this one so SCU can simply wait for either N-EVENT-REPORT
>> or for association to be closed by SCP. Or is this a bad assumption?
>>
>
>Very bad. The SCP shall never close an association opened by an SCU. The
only
>exception is an ABORT in response to a protocol violation.
I could not find such thing in the standard. The Performer (SCP or SCU) can
release the association orderly as well as the Invoker (SCU or SCP). The
conditions under which the Performer releases the association must be stated
in the Conformance Statement.
Also, may be, once the SCU has made the connection, the SCP may wish to send
not only one, but many notification requests.
Now, after all that has been said here, can I try to sumarise with a pseudo
code.
Looks like the SCU must have two processes (threads):
==========================================
//SCmt SCU Calling Process:
if( new SCmt event generated inside AE)
{
make association with the SCmt SCP;
Send SCmt RQ;
Recv SCmt RP;
Send ASSOC REL RQ;
loop:
Recv PDU;
if(PDU is SCmt Notif. RQ)
{
Update storage cmt. database;
send SCmt Notif.RP;
goto loop;
}else if(PDU is ASSOC REL RP){
close connection;
exit;
}else if(PDU is ASSOC REL RQ){
resolve release contention;
wait connection to close;
exit;
}
}
//SCmt SCU Listening Process:
if(new connection call from SCmt SCP)
{
respond and make association with SCmt SCP;
loop:
Recv PDU;
if(PDU is SCmt Notif. RQ)
{
update storage cmt. database;
send SCmt Notif.RP;
goto loop;
}else if(PDU is ASSOC REL RQ){
send ASSOC REL RP;
wait connection to close;
exit;
}
}
==============
========================
Similarly, the SCmt SCP can have two processes:
===================================
//SCmt SCP Listening Process:
if(new connection call from SCmt SCU)
{
respond and make association with SCmt SCU;
loop:
resv PDU;
if(PDU is SCmt RQ )
{
queue the SCmt request data;
send SCmt RP;
goto loop;
}else if(PDU is ASSOC REL RQ){
send ASSOC REL RP;
wait connection to close;
exit;
}
}
//SCmt SCP calling process:
if(new SCmt notification event generated inside AE)
{
make association with SCmt SCU;
send SCmt Notif.RQ;
recv SCmt Notif. RP;
update SCmt notification database;
send ASSOC REL RQ;
recv PDU
if(PDU is ASSOC REL RP){
close connection;
exit;
}else if(PDU is ASSOC REL RQ{
resolve release contention;
wait for connection to close;
exit;
}
}
=====================================
Do you think this is going to work?
Tod.
Dee Csipo
I did not have the energy to run through your pseudo code. I think you are
right to think that there is nothing in the standard that explicitly states that
the SCP can not orderly release the association (throw rocks, i did not take
the effort to check it :-) ), however I think it is a VERY BAD programming
practice. In client server architectures the management of the exchanges is
infinitely easier if the client is in control of the association. I do believe
that the standard is written in that spirit.
dee
;-D
David Clunie
DICOM is not really a client-server model but more of a peer-to-peer
arrangement. The guy initiating the association need not necessarily
be the one who closes it, nor even the SCU when SCU/SCP role negotiation
is used (e.g. in Storage Commitment). As I understand it the standard
was very much written with this in mind. An association is just an
open pipe on which a lot of things can happen in either direction.
It is more like a PPP connection to one's internet service provider
than an HTTP request/response after each of which (in 1.0) the connection
is closed.
Indeed if one doesn't think this way and assumes the association initiator
is in control all the time, and don't consider the alternatives, nasty
things may happen. Specifically, just because one sends some command
request and is awaiting the appropriate response, doesn't (always) mean
that the appropriate response is what you are going to be getting next,
and you shouldn't just freak and abort the association.
Now what would be really cool would be if more people implemented
asynchronous operations :)
david
--
Dee Csipo
Stone is accepted :-) I always get into trouble when i refer to the "Spirits" whether
bottled or not. In any case...... Thanks for the clarification. But (not in defense
of anything just to soapbox a little) as I wrote from a programming stand point of
view, it is much easier to handle the association control if one assumes that the
SCU (as client of the association) is in control of the association. The writer of
the SCP can make that decision really easily. That of course does not free the SCU
from handling the nasty surprises when the association closes under him. Further more
the message exchange and the association handling should not be intertwined.. It is
just by convention that the side making the association fires the first request in the
message exchange.
A peer to peer architecture if properly implemented is nothing but having both a
client and a server on both sides. If we start digging down further we can realize
that there in principal there are nothing more than clients and servers in multiple
layers and they have to adhere to very simple rules. If you start layering theses
little clients and servers and, on top of that dynamically change the composition of
the entities you can come up with very complicated structures. But dragging all that
back to the basics. Every action has a server (actor) a client (actor) a use case
(connection or message exchange) and an associated state transition.
So back to DICOMeese. In a SCP SCU relationship I have an association server on the
SCP by requirement. I may have one on the SCU depending on the support for reverse
role negotiation. I have am association client on the SCU by requirement, and if i
need to support reverse role negotiation from the SCP I need to have one on the SCP as
well.
I have a message exchange server on the SCP by requirement. If i decide to implement
any of the detached services (N-EVENT-REPORTs in general) I need to have a message
client on the SCP. I have a message client on the SCU and I may have a message server
on the SCU if I expect to service asynch services. My message servers and clients do
not give a rodent's behind about which way the association was established. It is
the job of internal interface between the message and connection entities to determine
if the requested action is permitted. In other words if i have an open association
and i try to use it from a message client it my have a rule in the association server
that will prevent me from doing that. (For all you UNIX driver geeks out there: does
not this look like nice little layers in a streams driver, where the rules of
accepting messages down the stack are encoded in the receiving side of the layers?)
Did that all make sense? All I did was I just decomposed everything into very easily
modeled objects. Now I just have to pull out my rusty-trusty UML generator and go to
town............
dee
;-D