3 Replies Latest reply on Jun 26, 2006 4:54 AM by Newsgroup_User

    Looking for some debug tips

    Level 7
      I have a director movie that can be run in one of two modes, host & peer.
      One person runs the projector as host, everyone else in peer mode. I am
      experiencing some difficulties when the host sends images to the peers and I
      am not sure about how to proceed to debug the problem.

      When the host sends out the media of a bitmap member to the connected peers,
      it prevents the peers from receiving any other messages for much longer than
      I would expect it to. For example, an image that is only 250k when saved as
      a file prevents the peer movies from either receiving or processing (not
      sure which) any further messages for several minutes even though everybody
      has a broadband internet connection.

      During this time, the peers can send messages to the host and they show up
      in the host movie quickly. The host movie is supposed to turn around an send
      the message to all of the peers (including the one that orginally sent the
      message). After several minutes the latency seems to clear and eventually
      all of the peers catch up and do show all of the messages they should have
      received.

      I would expects a small amount of latency, but for a small image and
      everyone on a relatively fast connection I would only expect it to be a few
      seconds, not 3-5 minutes. So I was wondering if anyone might be able to
      suggest so trouble shooting steps I might take. I don't know how to query
      the buffer to find out how much of the image has been sent by the host or
      received by the peer.

      Thanks Dave


        • 1. Re: Looking for some debug tips
          Level 7
          > For example, an image that is only 250k when saved as a file...
          If it's 250K when saved as a jpeg file, you are actually sending not 250K,
          but a few MBs most probably.
          Try saving that image as an rle compressed tga image to get an idea (aprox.)
          of the size of the media.

          > During this time, the peers can send messages to the host and they show up
          > in the host movie quickly.
          This is normal. A tcp socket has two buffers - one for sending and one for
          receiving. When e.g. the out (send) buffer is full, and new outgoing
          messages are being queued. However, new messages can be received, since the
          in (receive) buffer is empty:
          Host send > data to host out buffer > send > data to client's in buffer >
          client receive.
          During the 'send' period, the host's out and client's in buffers are
          occupied.
          When a client sends data to the host, the host will receive the data. But if
          the client sends data to another client that is also receiving data from the
          host, the second message (other client short message) will be received after
          the first message (host big message) is complete.

          Solution:
          Make sure that your images are saved as jpg and not modified on the fly.
          Then, use the undocumented .compressedMedia property instead of .media to
          send the member's media.
          When sending .media, director decompressed the member's media (if
          compressed), and then uses some kind of weak compression to generate the
          (media xxxx) value.
          If the member is a compressed member and you use the .compressed media, the
          original data (along with a small header) will be sent. That way, not only
          the message will be -much- shorter, but there also will be no host-side
          delay caused by the decompress/compress of the member's data.


          "Dave C" <private@email.com> wrote in message
          news:e7h55u$kmd$1@forums.macromedia.com...
          >I have a director movie that can be run in one of two modes, host & peer.
          > One person runs the projector as host, everyone else in peer mode. I am
          > experiencing some difficulties when the host sends images to the peers and
          > I
          > am not sure about how to proceed to debug the problem.
          >
          > When the host sends out the media of a bitmap member to the connected
          > peers,
          > it prevents the peers from receiving any other messages for much longer
          > than
          > I would expect it to. For example, an image that is only 250k when saved
          > as
          > a file prevents the peer movies from either receiving or processing (not
          > sure which) any further messages for several minutes even though everybody
          > has a broadband internet connection.
          >
          > During this time, the peers can send messages to the host and they show up
          > in the host movie quickly. The host movie is supposed to turn around an
          > send
          > the message to all of the peers (including the one that orginally sent the
          > message). After several minutes the latency seems to clear and eventually
          > all of the peers catch up and do show all of the messages they should have
          > received.
          >
          > I would expects a small amount of latency, but for a small image and
          > everyone on a relatively fast connection I would only expect it to be a
          > few
          > seconds, not 3-5 minutes. So I was wondering if anyone might be able to
          > suggest so trouble shooting steps I might take. I don't know how to query
          > the buffer to find out how much of the image has been sent by the host or
          > received by the peer.
          >
          > Thanks Dave
          >
          >



          • 2. Re: Looking for some debug tips
            Level 7
            Thanks, your explanation of tcp send & receive buffers fits exactly what I
            am experiencing. Very helpful. I am already using the compressedMedia
            property.

            So then the idea came to me to use two instances of the MUS xtra. One would
            be for sending short messages, the other for larger image data. This way,
            the program could still respond to the short messages (chat) while sending
            or receiving larger messages (images).

            I built a simple test and Director seems to have no problem creating 2
            instances of the MUS, each communicating over a different port. I haven't
            confirmed that this allows me to create a more robust program, but it seems
            perfectly reasonable. Are there any known issues I will encounter using this
            method?


            • 3. Re: Looking for some debug tips
              Level 7
              > Are there any known issues I will encounter using this
              > method?
              Other than using more resources (ports) no.
              TCP sockets support a thing called oob (out of bounds) data, that can be
              used -with caution- to send small messages during a large send/receive
              operation without having to create a second socket, but thats something the
              muXtra sure does not support.

              "Dave C" <private@email.com> wrote in message
              news:e7oepj$rdg$1@forums.macromedia.com...
              > Thanks, your explanation of tcp send & receive buffers fits exactly what I
              > am experiencing. Very helpful. I am already using the compressedMedia
              > property.
              >
              > So then the idea came to me to use two instances of the MUS xtra. One
              > would
              > be for sending short messages, the other for larger image data. This way,
              > the program could still respond to the short messages (chat) while sending
              > or receiving larger messages (images).
              >
              > I built a simple test and Director seems to have no problem creating 2
              > instances of the MUS, each communicating over a different port. I haven't
              > confirmed that this allows me to create a more robust program, but it
              > seems
              > perfectly reasonable. Are there any known issues I will encounter using
              > this
              > method?
              >
              >