Loading ...
Sorry, an error occurred while loading the content.

ClientEventReceive and TDI_RECIEVE_ENTIRE_MESSAGE

Expand Messages
  • lryp5446
    Hi, I am working on a TDI filter which monitors incoming data. I am confused with the meaning of various flags in ClientEventReceive callback. Under my
    Message 1 of 15 , Feb 10, 2005
    View Source
    • 0 Attachment
      Hi,

      I am working on a TDI filter which monitors incoming data. I am
      confused with the meaning of various flags in ClientEventReceive
      callback.

      Under my understanding, the size of the buffer at Tsdu is determined
      by BytesIndicated variable. In the case where TDI_RECEIVE_PARTIAL or
      TDI_RECEIVE_COPY_LOOKAHEAD is set, the BytesAvailable might be
      larger than BytesIndicated and this fact may say us that there is
      more data is Tsdu not yet available to TDI and that this data may be
      obtained by returning Irp and STATUS_MORE_PROCESSING_REQUIRED (or
      setting *BytesTaken = BytesIndicated and waiting for the next
      EventReceive callback).

      But, the problem occures when I receive the callback and all these
      conditions are met:

      1) BytesIndicated < BytesAvailable
      2) TDI_RECEIVE_ENTIRE_MESSAGE flag is set
      3) TDI_RECEIVE_COPY_LOOKAHED flag is set.

      How large is the buffer at Tsdu in such a situation? Does it
      contains BytesIndicated or BytesAvailable bytes - which I can read
      or copy (e.g. by TdiCopyLooakaheadData()).

      Thanks a lot, we have tried to debug this issue for some time, but
      cannot find a reliable answer.

      Lukas Rypacek.
    • Thomas F. Divine
      ... That is correct. ... No matter what the receive flags may be, this DDK comment applies: BytesIndicated Specifies the number of bytes of message-mode or
      Message 2 of 15 , Feb 10, 2005
      View Source
      • 0 Attachment
        > -----Original Message-----
        > From: lryp5446 [mailto:lukor@...]
        > Sent: Thursday, February 10, 2005 7:36 PM
        > To: discussion-pcausa@yahoogroups.com
        > Subject: [discussion-pcausa] ClientEventReceive and
        > TDI_RECIEVE_ENTIRE_MESSAGE
        >
        >
        >
        >
        > Hi,
        >
        > I am working on a TDI filter which monitors incoming data. I am
        > confused with the meaning of various flags in ClientEventReceive
        > callback.
        >
        > Under my understanding, the size of the buffer at Tsdu is determined
        > by BytesIndicated variable.

        That is correct.

        > In the case where TDI_RECEIVE_PARTIAL or
        > TDI_RECEIVE_COPY_LOOKAHEAD is set, the BytesAvailable might be
        > larger than BytesIndicated and this fact may say us that there is
        > more data is Tsdu not yet available to TDI and that this data may be
        > obtained by returning Irp and STATUS_MORE_PROCESSING_REQUIRED (or
        > setting *BytesTaken = BytesIndicated and waiting for the next
        > EventReceive callback).
        >
        > But, the problem occures when I receive the callback and all these
        > conditions are met:
        >
        > 1) BytesIndicated < BytesAvailable
        > 2) TDI_RECEIVE_ENTIRE_MESSAGE flag is set
        > 3) TDI_RECEIVE_COPY_LOOKAHEAD flag is set.
        >
        > How large is the buffer at Tsdu in such a situation? Does it
        > contains BytesIndicated or BytesAvailable bytes - which I can read
        > or copy (e.g. by TdiCopyLooakaheadData()).
        >

        No matter what the receive flags may be, this DDK comment applies:

        BytesIndicated
        Specifies the number of bytes of message-mode or stream-mode data in the
        buffer at Tsdu. This parameter is always less than or equal to the value of
        BytesAvailable. A TDI transport provides at least 128 bytes of data in a
        receive indication to its client, unless the received message or stream
        segment is less than 128 bytes in length. If BytesAvailable is greater than
        BytesIndicated, the transport has received data that it does not make
        available when it calls ClientEventReceive.

        With the flags that you mentioned above you must first copy all available
        bytes (BytesAvailable) into your own buffer. Then you can either:

        1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a TDI_RECEIVE request
        at IoRequestPacket to obtain the remaining TSDU data.

        2.) Return STATUS_SUCCESS and I _think_ that ClientEventReceive will be
        called again with the residual data. If not, then you may need to make a
        TDI_RECIEVE call to fetch it.

        Good luck,

        Thomas F. Divine

        > Thanks a lot, we have tried to debug this issue for some time, but
        > cannot find a reliable answer.
        >
        > Lukas Rypacek.
        >
        >
      • lryp5446
        Hi Thomas, thank you for your answer.I am still little confused. You mentioned ... But later on you suggest to copy BytesAvailable bytes to my buffers. Isn t
        Message 3 of 15 , Feb 11, 2005
        View Source
        • 0 Attachment
          Hi Thomas,
          thank you for your answer.I am still little confused. You mentioned
          that:

          > > Under my understanding, the size of the buffer at Tsdu is
          > > determined by BytesIndicated variable.
          >
          > That is correct.
          >

          And then again the note from DDK speaks about BytesIndicated:

          > No matter what the receive flags may be, this DDK comment applies:
          >
          > BytesIndicated
          > Specifies the number of bytes of message-mode or stream-mode data
          > in the buffer at Tsdu. This parameter is always less than or
          > equal to the value of BytesAvailable. A TDI transport provides
          > at least 128 bytes of data in a receive indication to its client,
          > unless the received message or stream segment is less than 128
          > bytes in length. If BytesAvailable is greater than BytesIndicated,
          > the transport has received data that it does not make available
          > when it calls ClientEventReceive.

          But later on you suggest to copy BytesAvailable bytes to my buffers.
          Isn't that a typo?

          >
          > With the flags that you mentioned above you must first copy
          > all available bytes (BytesAvailable) into your own buffer.
          > Then you can either:
          >
          > 1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a
          > TDI_RECEIVE request at IoRequestPacket to obtain the remaining
          > TSDU data.
          >
          > 2.) Return STATUS_SUCCESS and I _think_ that ClientEventReceive
          > will be called again with the residual data. If not, then you
          > may need to make a TDI_RECIEVE call to fetch it.
          >
          > Good luck,
          > Thomas F. Divine

          Many thanks again.
          Lukas Rypacek
        • Thomas F. Divine
          ... Yes, that is a typo. Sorry. Thomas F. Divine
          Message 4 of 15 , Feb 11, 2005
          View Source
          • 0 Attachment
            > -----Original Message-----
            > From: lryp5446 [mailto:lukor@...]
            > Sent: Friday, February 11, 2005 3:10 AM
            > To: discussion-pcausa@yahoogroups.com
            > Subject: [discussion-pcausa] Re: ClientEventReceive and
            > TDI_RECIEVE_ENTIRE_MESSAGE
            >
            >
            >
            >
            > Hi Thomas,
            > thank you for your answer.I am still little confused. You mentioned
            > that:
            >
            > > > Under my understanding, the size of the buffer at Tsdu is
            > determined
            > > > by BytesIndicated variable.
            > >
            > > That is correct.
            > >
            >
            > And then again the note from DDK speaks about BytesIndicated:
            >
            > > No matter what the receive flags may be, this DDK comment applies:
            > >
            > > BytesIndicated
            > > Specifies the number of bytes of message-mode or stream-mode data
            > > in the buffer at Tsdu. This parameter is always less than or
            > > equal to the value of BytesAvailable. A TDI transport provides
            > > at least 128 bytes of data in a receive indication to its client,
            > > unless the received message or stream segment is less than 128
            > > bytes in length. If BytesAvailable is greater than BytesIndicated,
            > > the transport has received data that it does not make available
            > > when it calls ClientEventReceive.
            >
            > But later on you suggest to copy BytesAvailable bytes to my buffers.
            > Isn't that a typo?

            Yes, that is a typo. Sorry.

            Thomas F. Divine

            >
            > >
            > > With the flags that you mentioned above you must first copy
            > > all indicated bytes (BytesIndicated) into your own buffer.
            > > Then you can either:
            > >
            > > 1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a TDI_RECEIVE
            > > request at IoRequestPacket to obtain the remaining TSDU data.
            > >
            > > 2.) Return STATUS_SUCCESS and I _think_ that
            > ClientEventReceive will
            > > be called again with the residual data. If not, then you
            > may need to
            > > make a TDI_RECIEVE call to fetch it.
            > >
            > > Good luck,
            > > Thomas F. Divine
            >
            > Many thanks again.
            > Lukas Rypacek
            >
            >
            >
            >
            >
            >
            > ----------------------
            >
            > Copyright C 1999-2005 Printing Communications Assoc., Inc. (PCAUSA)
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
          • tc_1020
            Hello Thomas, I have exactly the same problem. When I got a tdi recieve event callback with TDI_RECIEVE_ENTIRE_MESSAGE, but BytesIndicated is less than
            Message 5 of 15 , Jul 11, 2005
            View Source
            • 0 Attachment
              Hello Thomas,

              I have exactly the same problem. When I got a tdi recieve event
              callback with TDI_RECIEVE_ENTIRE_MESSAGE, but BytesIndicated is less
              than BytesAvailable, after I copied the BytesIndictaed to my buffer
              and set BytesTaken and return STATUS_SUCCESS, but TDI never calls me
              back again. Lukas Rypacek, are you seeing the same thing?

              So my question is do I have to setup my own irp and return
              STATUS_MORE_PROCESSING_REQUIRED? If I have to do it, do I have to
              allocate buffer equal to BytesAvailable-BytesIndicated?

              My another question is when will tdi call eventrecieve again?

              Thanks,

              Tom

              --- In discussion-pcausa@yahoogroups.com, "Thomas F. Divine"
              <tdivine@p...> wrote:
              >
              >
              > > -----Original Message-----
              > > From: lryp5446 [mailto:lukor@s...]
              > > Sent: Friday, February 11, 2005 3:10 AM
              > > To: discussion-pcausa@yahoogroups.com
              > > Subject: [discussion-pcausa] Re: ClientEventReceive and
              > > TDI_RECIEVE_ENTIRE_MESSAGE
              > >
              > >
              > >
              > >
              > > Hi Thomas,
              > > thank you for your answer.I am still little confused. You
              mentioned
              > > that:
              > >
              > > > > Under my understanding, the size of the buffer at Tsdu is
              > > determined
              > > > > by BytesIndicated variable.
              > > >
              > > > That is correct.
              > > >
              > >
              > > And then again the note from DDK speaks about BytesIndicated:
              > >
              > > > No matter what the receive flags may be, this DDK comment
              applies:
              > > >
              > > > BytesIndicated
              > > > Specifies the number of bytes of message-mode or stream-mode
              data
              > > > in the buffer at Tsdu. This parameter is always less than or
              > > > equal to the value of BytesAvailable. A TDI transport provides
              > > > at least 128 bytes of data in a receive indication to its
              client,
              > > > unless the received message or stream segment is less than 128
              > > > bytes in length. If BytesAvailable is greater than
              BytesIndicated,
              > > > the transport has received data that it does not make available
              > > > when it calls ClientEventReceive.
              > >
              > > But later on you suggest to copy BytesAvailable bytes to my
              buffers.
              > > Isn't that a typo?
              >
              > Yes, that is a typo. Sorry.
              >
              > Thomas F. Divine
              >
              > >
              > > >
              > > > With the flags that you mentioned above you must first copy
              > > > all indicated bytes (BytesIndicated) into your own buffer.
              > > > Then you can either:
              > > >
              > > > 1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a
              TDI_RECEIVE
              > > > request at IoRequestPacket to obtain the remaining TSDU data.
              > > >
              > > > 2.) Return STATUS_SUCCESS and I _think_ that
              > > ClientEventReceive will
              > > > be called again with the residual data. If not, then you
              > > may need to
              > > > make a TDI_RECIEVE call to fetch it.
              > > >
              > > > Good luck,
              > > > Thomas F. Divine
              > >
              > > Many thanks again.
              > > Lukas Rypacek
              > >
              > >
              > >
              > >
              > >
              > >
              > > ----------------------
              > >
              > > Copyright C 1999-2005 Printing Communications Assoc., Inc.
              (PCAUSA)
              > >
              > > Yahoo! Groups Links
              > >
              > >
              > >
              > >
              > >
              > >
              > >
              > >
            • Vijender
              I was working on TDI filters, when I observed similar problems. The simple principle for ClientEventReceive is: If you know that TDI has some data for you
              Message 6 of 15 , Jul 12, 2005
              View Source
              • 0 Attachment
                I was working on TDI filters, when I observed similar problems.

                The simple principle for ClientEventReceive is:
                If you know that TDI has some data for you (Consider BytesAvailable and
                not just BytesIndicated) which you have not accepted or received, it can
                be assumed that TDI will not call RECEIVE handler again.
                You will have to submit TDI_RECEIVE irp to get this data.

                I have provided the login in few lines. Please correct me if find
                problems in it.

                - Copy Indicated data (BytesIndicated) and set BytesTaken = Bytes Copied
                a) if BytesTaken = BytesIndicated && BytesIndicated
                =BytesAvailable
                - all indicated data has been copied
                i) set IRP = NULL, return STATUS_SUCCESS
                ii) setup TDI_RECEIVE irp and return
                STATUS_MORE_PROCESSING_REQUIRED (To get more data) (**)

                b) if BytesTaken <= BytesIndicated && BytesIndicated <
                BytesAvailable
                - all indicated data copied and more data is available
                with TDI
                i) setup TDI_RECEIVE irp with BufferSize = BytesAvailabe
                - BytesTaken and return STATUS_MORE_PROCESSING_REQUIRED (To get rest of
                data) (Buffer size can be more than rest of data also)
                ii) set IRP = NULL, return STATUS_SUCCESS. Later on
                subnet TDI_RECEIVE irp from other routines. TDI will not call receive
                handler untill you consume all of BytesAvailable data ( **)

                c) if BytesTaken = 0
                - No data consumed
                i) return STATUS_DATA_NOT_ACCEPTED. Later on submet
                TDI_RECEIVE irp to get BytesAvailable data
                ii) setup IRP and return STATUS_MORE_PROCESSING_REQUIRED
                to get all available data.

                **
                Not mentioned in DDK. Observed this behaviour of AFD and TDI in windows
                XP.

                Regards
                Vijender Yadav
                Systems Engineer
                Node Infotech Inc.
                ------------------------------------------------------------------------
                --------

                Message: 12
                Date: Tue, 12 Jul 2005 00:09:41 -0000
                From: "tc_1020" <tc_20@...>
                Subject: Re: ClientEventReceive and TDI_RECIEVE_ENTIRE_MESSAGE

                Hello Thomas,

                I have exactly the same problem. When I got a tdi recieve event
                callback with TDI_RECIEVE_ENTIRE_MESSAGE, but BytesIndicated is less
                than BytesAvailable, after I copied the BytesIndictaed to my buffer
                and set BytesTaken and return STATUS_SUCCESS, but TDI never calls me
                back again. Lukas Rypacek, are you seeing the same thing?

                So my question is do I have to setup my own irp and return
                STATUS_MORE_PROCESSING_REQUIRED? If I have to do it, do I have to
                allocate buffer equal to BytesAvailable-BytesIndicated?

                My another question is when will tdi call eventrecieve again?

                Thanks,

                Tom

                --- In discussion-pcausa@yahoogroups.com, "Thomas F. Divine"
                <tdivine@p...> wrote:
                >
                >
                > > -----Original Message-----
                > > From: lryp5446 [mailto:lukor@s...]
                > > Sent: Friday, February 11, 2005 3:10 AM
                > > To: discussion-pcausa@yahoogroups.com
                > > Subject: [discussion-pcausa] Re: ClientEventReceive and
                > > TDI_RECIEVE_ENTIRE_MESSAGE
                > >
                > >
                > >
                > >
                > > Hi Thomas,
                > > thank you for your answer.I am still little confused. You
                mentioned
                > > that:
                > >
                > > > > Under my understanding, the size of the buffer at Tsdu is
                > > determined
                > > > > by BytesIndicated variable.
                > > >
                > > > That is correct.
                > > >
                > >
                > > And then again the note from DDK speaks about BytesIndicated:
                > >
                > > > No matter what the receive flags may be, this DDK comment
                applies:
                > > >
                > > > BytesIndicated
                > > > Specifies the number of bytes of message-mode or stream-mode
                data
                > > > in the buffer at Tsdu. This parameter is always less than or
                > > > equal to the value of BytesAvailable. A TDI transport provides
                > > > at least 128 bytes of data in a receive indication to its
                client,
                > > > unless the received message or stream segment is less than 128
                > > > bytes in length. If BytesAvailable is greater than
                BytesIndicated,
                > > > the transport has received data that it does not make available
                > > > when it calls ClientEventReceive.
                > >
                > > But later on you suggest to copy BytesAvailable bytes to my
                buffers.
                > > Isn't that a typo?
                >
                > Yes, that is a typo. Sorry.
                >
                > Thomas F. Divine
                >
                > >
                > > >
                > > > With the flags that you mentioned above you must first copy all
                > > > indicated bytes (BytesIndicated) into your own buffer. Then you
                > > > can either:
                > > >
                > > > 1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a
                TDI_RECEIVE
                > > > request at IoRequestPacket to obtain the remaining TSDU data.
                > > >
                > > > 2.) Return STATUS_SUCCESS and I _think_ that
                > > ClientEventReceive will
                > > > be called again with the residual data. If not, then you
                > > may need to
                > > > make a TDI_RECIEVE call to fetch it.
                > > >
                > > > Good luck,
                > > > Thomas F. Divine
                > >
                > > Many thanks again.
                > > Lukas Rypacek
              • Tom Chen
                Thank Vijender for the clarification. Appreciate your reply.
                Message 7 of 15 , Jul 13, 2005
                View Source
                • 0 Attachment
                  Thank Vijender for the clarification. Appreciate your reply.


                  >From: "Vijender" <vijender@...>
                  >Reply-To: discussion-pcausa@yahoogroups.com
                  >To: <discussion-pcausa@yahoogroups.com>
                  >Subject: [discussion-pcausa] RE:ClientEventReceive and
                  >TDI_RECIEVE_ENTIRE_MESSAGE
                  >Date: Wed, 13 Jul 2005 11:34:06 +0530
                  >
                  >
                  >I was working on TDI filters, when I observed similar problems.
                  >
                  >The simple principle for ClientEventReceive is:
                  >If you know that TDI has some data for you (Consider BytesAvailable and
                  >not just BytesIndicated) which you have not accepted or received, it can
                  >be assumed that TDI will not call RECEIVE handler again.
                  >You will have to submit TDI_RECEIVE irp to get this data.
                  >
                  >I have provided the login in few lines. Please correct me if find
                  >problems in it.
                  >
                  >- Copy Indicated data (BytesIndicated) and set BytesTaken = Bytes Copied
                  > a) if BytesTaken = BytesIndicated && BytesIndicated
                  >=BytesAvailable
                  > - all indicated data has been copied
                  > i) set IRP = NULL, return STATUS_SUCCESS
                  > ii) setup TDI_RECEIVE irp and return
                  >STATUS_MORE_PROCESSING_REQUIRED (To get more data) (**)
                  >
                  > b) if BytesTaken <= BytesIndicated && BytesIndicated <
                  >BytesAvailable
                  > - all indicated data copied and more data is available
                  >with TDI
                  > i) setup TDI_RECEIVE irp with BufferSize = BytesAvailabe
                  >- BytesTaken and return STATUS_MORE_PROCESSING_REQUIRED (To get rest of
                  >data) (Buffer size can be more than rest of data also)
                  > ii) set IRP = NULL, return STATUS_SUCCESS. Later on
                  >subnet TDI_RECEIVE irp from other routines. TDI will not call receive
                  >handler untill you consume all of BytesAvailable data ( **)
                  >
                  > c) if BytesTaken = 0
                  > - No data consumed
                  > i) return STATUS_DATA_NOT_ACCEPTED. Later on submet
                  >TDI_RECEIVE irp to get BytesAvailable data
                  > ii) setup IRP and return STATUS_MORE_PROCESSING_REQUIRED
                  >to get all available data.
                  >
                  >**
                  >Not mentioned in DDK. Observed this behaviour of AFD and TDI in windows
                  >XP.
                  >
                  >Regards
                  >Vijender Yadav
                  >Systems Engineer
                  >Node Infotech Inc.
                  >------------------------------------------------------------------------
                  >--------
                  >
                  >Message: 12
                  > Date: Tue, 12 Jul 2005 00:09:41 -0000
                  > From: "tc_1020" <tc_20@...>
                  >Subject: Re: ClientEventReceive and TDI_RECIEVE_ENTIRE_MESSAGE
                  >
                  >Hello Thomas,
                  >
                  >I have exactly the same problem. When I got a tdi recieve event
                  >callback with TDI_RECIEVE_ENTIRE_MESSAGE, but BytesIndicated is less
                  >than BytesAvailable, after I copied the BytesIndictaed to my buffer
                  >and set BytesTaken and return STATUS_SUCCESS, but TDI never calls me
                  >back again. Lukas Rypacek, are you seeing the same thing?
                  >
                  >So my question is do I have to setup my own irp and return
                  >STATUS_MORE_PROCESSING_REQUIRED? If I have to do it, do I have to
                  >allocate buffer equal to BytesAvailable-BytesIndicated?
                  >
                  >My another question is when will tdi call eventrecieve again?
                  >
                  >Thanks,
                  >
                  >Tom
                  >
                  >--- In discussion-pcausa@yahoogroups.com, "Thomas F. Divine"
                  ><tdivine@p...> wrote:
                  > >
                  > >
                  > > > -----Original Message-----
                  > > > From: lryp5446 [mailto:lukor@s...]
                  > > > Sent: Friday, February 11, 2005 3:10 AM
                  > > > To: discussion-pcausa@yahoogroups.com
                  > > > Subject: [discussion-pcausa] Re: ClientEventReceive and
                  > > > TDI_RECIEVE_ENTIRE_MESSAGE
                  > > >
                  > > >
                  > > >
                  > > >
                  > > > Hi Thomas,
                  > > > thank you for your answer.I am still little confused. You
                  >mentioned
                  > > > that:
                  > > >
                  > > > > > Under my understanding, the size of the buffer at Tsdu is
                  > > > determined
                  > > > > > by BytesIndicated variable.
                  > > > >
                  > > > > That is correct.
                  > > > >
                  > > >
                  > > > And then again the note from DDK speaks about BytesIndicated:
                  > > >
                  > > > > No matter what the receive flags may be, this DDK comment
                  >applies:
                  > > > >
                  > > > > BytesIndicated
                  > > > > Specifies the number of bytes of message-mode or stream-mode
                  >data
                  > > > > in the buffer at Tsdu. This parameter is always less than or
                  > > > > equal to the value of BytesAvailable. A TDI transport provides
                  > > > > at least 128 bytes of data in a receive indication to its
                  >client,
                  > > > > unless the received message or stream segment is less than 128
                  > > > > bytes in length. If BytesAvailable is greater than
                  >BytesIndicated,
                  > > > > the transport has received data that it does not make available
                  > > > > when it calls ClientEventReceive.
                  > > >
                  > > > But later on you suggest to copy BytesAvailable bytes to my
                  >buffers.
                  > > > Isn't that a typo?
                  > >
                  > > Yes, that is a typo. Sorry.
                  > >
                  > > Thomas F. Divine
                  > >
                  > > >
                  > > > >
                  > > > > With the flags that you mentioned above you must first copy all
                  > > > > indicated bytes (BytesIndicated) into your own buffer. Then you
                  > > > > can either:
                  > > > >
                  > > > > 1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a
                  >TDI_RECEIVE
                  > > > > request at IoRequestPacket to obtain the remaining TSDU data.
                  > > > >
                  > > > > 2.) Return STATUS_SUCCESS and I _think_ that
                  > > > ClientEventReceive will
                  > > > > be called again with the residual data. If not, then you
                  > > > may need to
                  > > > > make a TDI_RECIEVE call to fetch it.
                  > > > >
                  > > > > Good luck,
                  > > > > Thomas F. Divine
                  > > >
                  > > > Many thanks again.
                  > > > Lukas Rypacek
                  >
                  >
                  >
                  >----------------------
                  >
                  >Copyright (c) 1999-2005 Printing Communications Assoc., Inc. (PCAUSA)
                  >
                  >Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                • Tom Chen
                  Hello Vijender, I have another question, when I need to setup tdi recieve to get available data, do I have to setup a buffer of exactly the size of
                  Message 8 of 15 , Jul 13, 2005
                  View Source
                  • 0 Attachment
                    Hello Vijender,

                    I have another question, when I need to setup tdi recieve to get "available"
                    data, do I have to setup a buffer of exactly the size of
                    "BytesAvailable-BytesTaken"? Can I setup a smaller buffer first and then try
                    to get the remaining data?

                    Thanks,

                    Tom

                    >From: "Tom Chen" <tc_20@...>
                    >Reply-To: discussion-pcausa@yahoogroups.com
                    >To: discussion-pcausa@yahoogroups.com
                    >Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                    >TDI_RECIEVE_ENTIRE_MESSAGE
                    >Date: Wed, 13 Jul 2005 13:33:49 -0400
                    >
                    >
                    >Thank Vijender for the clarification. Appreciate your reply.
                    >
                    >
                    > >From: "Vijender" <vijender@...>
                    > >Reply-To: discussion-pcausa@yahoogroups.com
                    > >To: <discussion-pcausa@yahoogroups.com>
                    > >Subject: [discussion-pcausa] RE:ClientEventReceive and
                    > >TDI_RECIEVE_ENTIRE_MESSAGE
                    > >Date: Wed, 13 Jul 2005 11:34:06 +0530
                    > >
                    > >
                    > >I was working on TDI filters, when I observed similar problems.
                    > >
                    > >The simple principle for ClientEventReceive is:
                    > >If you know that TDI has some data for you (Consider BytesAvailable and
                    > >not just BytesIndicated) which you have not accepted or received, it can
                    > >be assumed that TDI will not call RECEIVE handler again.
                    > >You will have to submit TDI_RECEIVE irp to get this data.
                    > >
                    > >I have provided the login in few lines. Please correct me if find
                    > >problems in it.
                    > >
                    > >- Copy Indicated data (BytesIndicated) and set BytesTaken = Bytes Copied
                    > > a) if BytesTaken = BytesIndicated && BytesIndicated
                    > >=BytesAvailable
                    > > - all indicated data has been copied
                    > > i) set IRP = NULL, return STATUS_SUCCESS
                    > > ii) setup TDI_RECEIVE irp and return
                    > >STATUS_MORE_PROCESSING_REQUIRED (To get more data) (**)
                    > >
                    > > b) if BytesTaken <= BytesIndicated && BytesIndicated <
                    > >BytesAvailable
                    > > - all indicated data copied and more data is available
                    > >with TDI
                    > > i) setup TDI_RECEIVE irp with BufferSize = BytesAvailabe
                    > >- BytesTaken and return STATUS_MORE_PROCESSING_REQUIRED (To get rest of
                    > >data) (Buffer size can be more than rest of data also)
                    > > ii) set IRP = NULL, return STATUS_SUCCESS. Later on
                    > >subnet TDI_RECEIVE irp from other routines. TDI will not call receive
                    > >handler untill you consume all of BytesAvailable data ( **)
                    > >
                    > > c) if BytesTaken = 0
                    > > - No data consumed
                    > > i) return STATUS_DATA_NOT_ACCEPTED. Later on submet
                    > >TDI_RECEIVE irp to get BytesAvailable data
                    > > ii) setup IRP and return STATUS_MORE_PROCESSING_REQUIRED
                    > >to get all available data.
                    > >
                    > >**
                    > >Not mentioned in DDK. Observed this behaviour of AFD and TDI in windows
                    > >XP.
                    > >
                    > >Regards
                    > >Vijender Yadav
                    > >Systems Engineer
                    > >Node Infotech Inc.
                    > >------------------------------------------------------------------------
                    > >--------
                    > >
                    > >Message: 12
                    > > Date: Tue, 12 Jul 2005 00:09:41 -0000
                    > > From: "tc_1020" <tc_20@...>
                    > >Subject: Re: ClientEventReceive and TDI_RECIEVE_ENTIRE_MESSAGE
                    > >
                    > >Hello Thomas,
                    > >
                    > >I have exactly the same problem. When I got a tdi recieve event
                    > >callback with TDI_RECIEVE_ENTIRE_MESSAGE, but BytesIndicated is less
                    > >than BytesAvailable, after I copied the BytesIndictaed to my buffer
                    > >and set BytesTaken and return STATUS_SUCCESS, but TDI never calls me
                    > >back again. Lukas Rypacek, are you seeing the same thing?
                    > >
                    > >So my question is do I have to setup my own irp and return
                    > >STATUS_MORE_PROCESSING_REQUIRED? If I have to do it, do I have to
                    > >allocate buffer equal to BytesAvailable-BytesIndicated?
                    > >
                    > >My another question is when will tdi call eventrecieve again?
                    > >
                    > >Thanks,
                    > >
                    > >Tom
                    > >
                    > >--- In discussion-pcausa@yahoogroups.com, "Thomas F. Divine"
                    > ><tdivine@p...> wrote:
                    > > >
                    > > >
                    > > > > -----Original Message-----
                    > > > > From: lryp5446 [mailto:lukor@s...]
                    > > > > Sent: Friday, February 11, 2005 3:10 AM
                    > > > > To: discussion-pcausa@yahoogroups.com
                    > > > > Subject: [discussion-pcausa] Re: ClientEventReceive and
                    > > > > TDI_RECIEVE_ENTIRE_MESSAGE
                    > > > >
                    > > > >
                    > > > >
                    > > > >
                    > > > > Hi Thomas,
                    > > > > thank you for your answer.I am still little confused. You
                    > >mentioned
                    > > > > that:
                    > > > >
                    > > > > > > Under my understanding, the size of the buffer at Tsdu is
                    > > > > determined
                    > > > > > > by BytesIndicated variable.
                    > > > > >
                    > > > > > That is correct.
                    > > > > >
                    > > > >
                    > > > > And then again the note from DDK speaks about BytesIndicated:
                    > > > >
                    > > > > > No matter what the receive flags may be, this DDK comment
                    > >applies:
                    > > > > >
                    > > > > > BytesIndicated
                    > > > > > Specifies the number of bytes of message-mode or stream-mode
                    > >data
                    > > > > > in the buffer at Tsdu. This parameter is always less than or
                    > > > > > equal to the value of BytesAvailable. A TDI transport provides
                    > > > > > at least 128 bytes of data in a receive indication to its
                    > >client,
                    > > > > > unless the received message or stream segment is less than 128
                    > > > > > bytes in length. If BytesAvailable is greater than
                    > >BytesIndicated,
                    > > > > > the transport has received data that it does not make available
                    > > > > > when it calls ClientEventReceive.
                    > > > >
                    > > > > But later on you suggest to copy BytesAvailable bytes to my
                    > >buffers.
                    > > > > Isn't that a typo?
                    > > >
                    > > > Yes, that is a typo. Sorry.
                    > > >
                    > > > Thomas F. Divine
                    > > >
                    > > > >
                    > > > > >
                    > > > > > With the flags that you mentioned above you must first copy all
                    > > > > > indicated bytes (BytesIndicated) into your own buffer. Then you
                    > > > > > can either:
                    > > > > >
                    > > > > > 1.) Return STATUS_MORE_PROCESSING_REQUIRED and supply a
                    > >TDI_RECEIVE
                    > > > > > request at IoRequestPacket to obtain the remaining TSDU data.
                    > > > > >
                    > > > > > 2.) Return STATUS_SUCCESS and I _think_ that
                    > > > > ClientEventReceive will
                    > > > > > be called again with the residual data. If not, then you
                    > > > > may need to
                    > > > > > make a TDI_RECIEVE call to fetch it.
                    > > > > >
                    > > > > > Good luck,
                    > > > > > Thomas F. Divine
                    > > > >
                    > > > > Many thanks again.
                    > > > > Lukas Rypacek
                    > >
                    > >
                    > >
                    > >----------------------
                    > >
                    > >Copyright (c) 1999-2005 Printing Communications Assoc., Inc. (PCAUSA)
                    > >
                    > >Yahoo! Groups Links
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    >
                    >
                    >
                    >
                    >----------------------
                    >
                    >Copyright (c) 1999-2005 Printing Communications Assoc., Inc. (PCAUSA)
                    >
                    >Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                  • Thomas F. Divine
                    ... Yes, your TDI Receive can be of any size. It can be less than the difference you identified above - or even larger. Does your protocol use fixed-size
                    Message 9 of 15 , Jul 13, 2005
                    View Source
                    • 0 Attachment
                      > -----Original Message-----
                      > From: discussion-pcausa@yahoogroups.com
                      > [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of Tom Chen
                      > Sent: Wednesday, July 13, 2005 2:33 PM
                      > To: discussion-pcausa@yahoogroups.com
                      > Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                      > TDI_RECIEVE_ENTIRE_MESSAGE
                      >
                      > Hello Vijender,
                      >
                      > I have another question, when I need to setup tdi recieve to
                      > get "available"
                      > data, do I have to setup a buffer of exactly the size of
                      > "BytesAvailable-BytesTaken"? Can I setup a smaller buffer
                      > first and then try to get the remaining data?
                      >

                      Yes, your TDI Receive can be of any size. It can be less than the difference
                      you identified above - or even larger.

                      Does your "protocol" use fixed-size headers followed by variable-length
                      data? If so, then there are some strategies that work pretty well. Let me
                      know.

                      Thomas F. Divine
                    • Tom Chen
                      Thomas, Thanks for the reply. My protocol is fixed header plus variable length. I read from the list that if I use tdi recieve, there is a perormance penality,
                      Message 10 of 15 , Jul 13, 2005
                      View Source
                      • 0 Attachment
                        Thomas,

                        Thanks for the reply.

                        My protocol is fixed header plus variable length. I read from the list that
                        if I use tdi recieve, there is a perormance penality, so I'd like to use
                        event driven model. Then I ran into the problem sometimes I have to use tdi
                        recieve. Any suggestions?

                        Thanks,

                        Tom

                        >From: "Thomas F. Divine" <tdivine@...>
                        >Reply-To: discussion-pcausa@yahoogroups.com
                        >To: <discussion-pcausa@yahoogroups.com>
                        >Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                        >TDI_RECIEVE_ENTIRE_MESSAGE
                        >Date: Wed, 13 Jul 2005 14:40:33 -0400
                        >
                        >
                        >
                        > > -----Original Message-----
                        > > From: discussion-pcausa@yahoogroups.com
                        > > [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of Tom Chen
                        > > Sent: Wednesday, July 13, 2005 2:33 PM
                        > > To: discussion-pcausa@yahoogroups.com
                        > > Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                        > > TDI_RECIEVE_ENTIRE_MESSAGE
                        > >
                        > > Hello Vijender,
                        > >
                        > > I have another question, when I need to setup tdi recieve to
                        > > get "available"
                        > > data, do I have to setup a buffer of exactly the size of
                        > > "BytesAvailable-BytesTaken"? Can I setup a smaller buffer
                        > > first and then try to get the remaining data?
                        > >
                        >
                        >Yes, your TDI Receive can be of any size. It can be less than the
                        >difference
                        >you identified above - or even larger.
                        >
                        >Does your "protocol" use fixed-size headers followed by variable-length
                        >data? If so, then there are some strategies that work pretty well. Let me
                        >know.
                        >
                        >Thomas F. Divine
                        >
                        >
                        >
                        >
                        >
                        >----------------------
                        >
                        >Copyright (c) 1999-2005 Printing Communications Assoc., Inc. (PCAUSA)
                        >
                        >Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >
                      • Thomas F. Divine
                        ... Frankly, I d consider this sort of strategy. I think it will make your driver simpler - and probably won t have a performance penalty at all. In your kind
                        Message 11 of 15 , Jul 13, 2005
                        View Source
                        • 0 Attachment
                          > -----Original Message-----
                          > From: discussion-pcausa@yahoogroups.com
                          > [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of Tom Chen
                          > Sent: Wednesday, July 13, 2005 3:52 PM
                          > To: discussion-pcausa@yahoogroups.com
                          > Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                          > TDI_RECIEVE_ENTIRE_MESSAGE
                          >
                          > Thomas,
                          >
                          > Thanks for the reply.
                          >
                          > My protocol is fixed header plus variable length. I read from
                          > the list that if I use tdi recieve, there is a perormance
                          > penality, so I'd like to use event driven model. Then I ran
                          > into the problem sometimes I have to use tdi recieve. Any suggestions?
                          >
                          > Thanks,
                          >
                          > Tom
                          >
                          Frankly, I'd consider this sort of strategy. I think it will make your
                          driver simpler - and probably won't have a performance penalty at all.

                          In your kind of protocol it eliminates much of the "state" management that
                          you would have using other approaches. My suggestion is:

                          1.) Don't use an EventHandler at all. Instead, when you start post a TDI
                          Receive for exactly the size of your fixed-length header. Have a callback
                          for this receive that's called ReceiveHeader.

                          2.) When ReceiveHeader is called you will have the header data. Examine the
                          header for the length of the following variable-length data. If you can
                          swallow the variable-length data in one reasonably-sized buffer, just post a
                          TDI Receive call to fetch the following variable-length data. For this TDI
                          Receive specify a different callback that's called ReceiveData.

                          3.) When your ReceiveData callback is called, process the variable-length
                          data. When done, go back to Step 1.

                          With this scheme you are always either in the state of "Waiting to Receive
                          Header" or "Waiting to Receive Data". Because you have different callbacks
                          to receive the header and to receive the data you don't have to worry about
                          state. This scheme can only fail if something totally unrecoverable happens.

                          This may be the approach you are already using. If so, keep using it UNLESS
                          you KNOW that you have a performance issue. Only use the more complex
                          EventHandler approach if you KNOW that you have a problem.

                          There is always a tradeoff between reliability/simplicity and
                          performance/complexity. I subscribe to the KISS theory for myself ("Keep It
                          Simple, Stupid!") until there is a definite requirement to use something
                          more complex.

                          Thomas F. Divine
                        • Tom Chen
                          Thanks for the suggestion. It does simplify the coding a lot. Appreciate your help. Tom
                          Message 12 of 15 , Jul 13, 2005
                          View Source
                          • 0 Attachment
                            Thanks for the suggestion. It does simplify the coding a lot. Appreciate
                            your help.

                            Tom


                            >From: "Thomas F. Divine" <tdivine@...>
                            >Reply-To: discussion-pcausa@yahoogroups.com
                            >To: <discussion-pcausa@yahoogroups.com>
                            >Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                            >TDI_RECIEVE_ENTIRE_MESSAGE
                            >Date: Wed, 13 Jul 2005 16:13:34 -0400
                            >
                            >
                            >
                            > > -----Original Message-----
                            > > From: discussion-pcausa@yahoogroups.com
                            > > [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of Tom Chen
                            > > Sent: Wednesday, July 13, 2005 3:52 PM
                            > > To: discussion-pcausa@yahoogroups.com
                            > > Subject: RE: [discussion-pcausa] RE:ClientEventReceive and
                            > > TDI_RECIEVE_ENTIRE_MESSAGE
                            > >
                            > > Thomas,
                            > >
                            > > Thanks for the reply.
                            > >
                            > > My protocol is fixed header plus variable length. I read from
                            > > the list that if I use tdi recieve, there is a perormance
                            > > penality, so I'd like to use event driven model. Then I ran
                            > > into the problem sometimes I have to use tdi recieve. Any suggestions?
                            > >
                            > > Thanks,
                            > >
                            > > Tom
                            > >
                            >Frankly, I'd consider this sort of strategy. I think it will make your
                            >driver simpler - and probably won't have a performance penalty at all.
                            >
                            >In your kind of protocol it eliminates much of the "state" management that
                            >you would have using other approaches. My suggestion is:
                            >
                            >1.) Don't use an EventHandler at all. Instead, when you start post a TDI
                            >Receive for exactly the size of your fixed-length header. Have a callback
                            >for this receive that's called ReceiveHeader.
                            >
                            >2.) When ReceiveHeader is called you will have the header data. Examine the
                            >header for the length of the following variable-length data. If you can
                            >swallow the variable-length data in one reasonably-sized buffer, just post
                            >a
                            >TDI Receive call to fetch the following variable-length data. For this TDI
                            >Receive specify a different callback that's called ReceiveData.
                            >
                            >3.) When your ReceiveData callback is called, process the variable-length
                            >data. When done, go back to Step 1.
                            >
                            >With this scheme you are always either in the state of "Waiting to Receive
                            >Header" or "Waiting to Receive Data". Because you have different callbacks
                            >to receive the header and to receive the data you don't have to worry about
                            >state. This scheme can only fail if something totally unrecoverable
                            >happens.
                            >
                            >This may be the approach you are already using. If so, keep using it UNLESS
                            >you KNOW that you have a performance issue. Only use the more complex
                            >EventHandler approach if you KNOW that you have a problem.
                            >
                            >There is always a tradeoff between reliability/simplicity and
                            >performance/complexity. I subscribe to the KISS theory for myself ("Keep It
                            >Simple, Stupid!") until there is a definite requirement to use something
                            >more complex.
                            >
                            >Thomas F. Divine
                            >
                            >
                            >
                            >
                            >----------------------
                            >
                            >Copyright (c) 1999-2005 Printing Communications Assoc., Inc. (PCAUSA)
                            >
                            >Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                            >
                          • rajat gogri
                            Hello, Can anyone tell me how o receive beacon Packets using NDIS ? Could anyone send me the code to do the same. basically i want to create small module which
                            Message 13 of 15 , Jul 19, 2005
                            View Source
                            • 0 Attachment

                              Hello,

                              Can anyone tell me how o receive beacon Packets using NDIS ? Could anyone send me the code to do the same. basically i want to create small module which receives beacon packets using NDIS ..

                              Thanks in advance,

                              Rajat



                              love rajat
                              raj_arc@...
                              Cell no:98191-44566
                               


                              Start your day with Yahoo! - make it your home page
                            • Thomas F. Divine
                              _____ From: discussion-pcausa@yahoogroups.com [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of rajat gogri Sent: Tuesday, July 19, 2005 6:13 AM To:
                              Message 14 of 15 , Jul 19, 2005
                              View Source
                              • 0 Attachment
                                 


                                From: discussion-pcausa@yahoogroups.com [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of rajat gogri
                                Sent: Tuesday, July 19, 2005 6:13 AM
                                To: discussion-pcausa@yahoogroups.com
                                Subject: [discussion-pcausa] Query to receive Beacon Packets

                                Hello,

                                Can anyone tell me how o receive beacon Packets using NDIS ? Could anyone send me the code to do the same. basically i want to create small module which receives beacon packets using NDIS .. 

                                I don't think that current versions of Windows will allow you to fetch Native 802.11 packets - including Beacon packets.

                                If it is possible to fetch beacon packets, then you would need proprietary information from you adapter vendor.

                                Perhaps in Longhorn...

                                Thomas F. Divine

                                Thanks in advance,

                                Rajat

                              • rajat gogri
                                Thanks for ur reply. Ya may ne widows NDIS driver might not allow that but if my application directly sit on NDIS miniport driver than is it possible to
                                Message 15 of 15 , Jul 19, 2005
                                View Source
                                • 0 Attachment
                                  Thanks for ur reply.
                                   
                                  Ya may ne widows NDIS driver might not allow that but if my application directly sit on NDIS miniport driver than is it  possible to retreive the packets???
                                   
                                  Cheers,
                                  Rajat

                                  "Thomas F. Divine" <tdivine@...> wrote:
                                   


                                  From: discussion-pcausa@yahoogroups.com [mailto:discussion-pcausa@yahoogroups.com] On Behalf Of rajat gogri
                                  Sent: Tuesday, July 19, 2005 6:13 AM
                                  To: discussion-pcausa@yahoogroups.com
                                  Subject: [discussion-pcausa] Query to receive Beacon Packets

                                  Hello,

                                  Can anyone tell me how o receive beacon Packets using NDIS ? Could anyone send me the code to do the same. basically i want to create small module which receives beacon packets using NDIS .. 

                                  I don't think that current versions of Windows will allow you to fetch Native 802.11 packets - including Beacon packets.

                                  If it is possible to fetch beacon packets, then you would need proprietary information from you adapter vendor.

                                  Perhaps in Longhorn...

                                  Thomas F. Divine

                                  Thanks in advance,

                                  Rajat



                                  love rajat
                                  raj_arc@...
                                  Cell no:98191-44566
                                   


                                  Start your day with Yahoo! - make it your home page

                                Your message has been successfully submitted and would be delivered to recipients shortly.