2 Replies Latest reply on Aug 28, 2007 7:21 AM by billbailey1964

    readUTFBytes() does not return bytesAvailable bytes

    billbailey1964
      I am using an open source API called XIFF which is written in ActionScript 3.0. In the event handler method for flash.net.Socket ProgressEvent's, it calls readUTFBytes(bytesAvailable) ... but the length of the string returned is nowhere near the length in bytes that availableBytes says is available. In this case, numerous separate messages arrive in close succession and they are concatenated in a single ProgressEvent ... but I can't read all of the messages because the call to readUTFBytes() never returns all the bytes even though after completion availableBytes is reset to 0.

      What could cause readUTFBytes() not to read all of the availableBytes? This seems to me a bug, but I can't find any other record of anyone reporting problems with this method ... is anyone else using it successfully?

      Thanks, Bill.
        • 1. readUTFBytes() does not return bytesAvailable bytes
          levancho Level 3
          I think you have a mixed encoding problem
          I am not familiar with that API but from what you have written,
          readUTFBytes is expecting an UTF8 (3byte per character) stream
          so that means if stream is "ABCD" in binary stream needs to equal to 3X8 which is of 24 bits per character and for all Four characters 24X4 = 96bits so total stream got to be 96 bits... but if "ABCD" stream is not in UTF8 encoding it will be lot smaller just 4X8 = 36.and thats where issue of able to read only partial data happens(I think, there are a lot of speculation, just putting my thoughs fo your to consider) so make sure stream is in utf8 ecoding, might fix the issue.

          • 2. Re: readUTFBytes() does not return bytesAvailable bytes
            billbailey1964 Level 1
            Thanks for the feedback. Unfortunately, the data is coming from a server I didn't write (OpenFire chat server) so it may be tricky for me to determine exactly how the stream is encoded. It is worth noting that if I use an older XIFF class which uses XMLSocket instead of Socket, it reads the response just fine ... so I don't think there is anything really wierd going on in the stream ... but it's hard to say anything for sure. I am using the old connection class for now as a workaround, but I'd like to figure out why the new one isn't working ... unfortunately, its open source and the authors are providing next to non-existent support so far ... so I thought I'd try to fix it myself just like I did the last dozen bugs I found. :)