Interleaving PDU's - DICOM

This is a discussion on Interleaving PDU's - DICOM ; Hi folks, I am looking at implementing a new low level DICOM toolkit in perl (no, this is not a joke, and it may not be as pathetic as you think). Anyway, I have been taking a fresh look at ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Interleaving PDU's

  1. Interleaving PDU's

    Hi folks,
    I am looking at implementing a new low level DICOM toolkit in perl
    (no, this is not a joke, and it may not be as pathetic as you think).
    Anyway, I have been taking a fresh look at Parts 7 and 8 of the
    standard, and a question has come up (in my mind, anyway).

    If you negotiate an asynchronous window, then the SCU could
    conceivably start sending a second Object before completing sending of
    the first object. Of course, if the objects were sent on the same
    presentation context, then the SCP wouldn't be able to sort out the P-
    DATA-PDU's, and both sends would fail. However, if the objects were
    sent on different presentation contexts, then (conceivably) the SCP
    could sort out the P-DATA-PDU's by presentation context and re-
    assemble to objects correctly. I don't think anyone does this (I
    don't really think it should be allowed, either), but I can't find the
    place in the standard where it is forbidden. I'm thinking maybe a CP
    might be in order to close this loophole (or perhaps someone can point
    me at the place in the standard where it is forbidden, perhaps
    implicitly).

    However, if any toolkit makers have actually implemented this
    functionality, then a CP would break their implementation (or at
    least make it illegal). I don't know how widely asynchronous window
    negotiation has been implemented.

    Anyone have an opinion on this?

    Bill Bennett


  2. Re: Interleaving PDU's

    Hi Bill,
    interesting topic and you are right, it would not work. However
    fortunately the standard does say:

    "Furthermore, no fragments of any other message shall be sent until
    all fragments of the current message have been sent (i.e. interleaving
    of fragments from different messages is not permitted)."

    You can find the statement in part 8 Annex E1 encapsulation rules. In
    other words the asynchronous operations refers to service, not PDU
    level. So you can invoke another notification/operation once the last
    one is completely sent but without waiting for the response.

    Thomas



  3. Re: Interleaving PDU's

    Yep. I had just found it when I noticed your reply. You think you
    know your way around the standard, and then....

    Thanks,
    Bill B.
    On Aug 8, 10:45 am, Thomas Freier wrote:
    > Hi Bill,
    > interesting topic and you are right, it would not work. However
    > fortunately the standard does say:
    >
    > "Furthermore, no fragments of any other message shall be sent until
    > all fragments of the current message have been sent (i.e. interleaving
    > of fragments from different messages is not permitted)."
    >
    > You can find the statement in part 8 Annex E1 encapsulation rules. In
    > other words the asynchronous operations refers to service, not PDU
    > level. So you can invoke another notification/operation once the last
    > one is completely sent but without waiting for the response.
    >
    > Thomas




+ Reply to Thread