I'm not understanding something here - in the following excerpted and
simplified example, I'm trying to send a ByteArray of length 170 and there seem
to be 173 bytes received. Where are the extra bytes coming from and and is
that the reason readObject returns null? (tracing _socketData.toString
Mattheis, Erik (MIN-WSW) skriver:
I'm not understanding something here - in the following excerpted and
simplified example, I'm trying to send a ByteArray of length 170 and there
seem to be 173 bytes received. Where are the extra bytes coming from and
and is that the reason readObject
On 2/16/12 4:20 PM, Henrik Andersson he...@henke37.cjb.net wrote:
It is highly possible that multiple writes was stuffed into one read,
even if you don't flush between the writes.
The three left over bytes could be the first three bytes of the length
of the next object.
I left out some of the
Mattheis, Erik (MIN-WSW) skriver:
On 2/16/12 4:20 PM, Henrik Andersson he...@henke37.cjb.net wrote:
It is highly possible that multiple writes was stuffed into one read,
even if you don't flush between the writes.
The three left over bytes could be the first three bytes of the length
of the
In my server app I was performing ByteArray.writeObject(MyObjectToSend) to
assemble MyByteArray and then again using Socket.writeObject(MyByteArray) when
actually sending it. This created an AMF encoded object within an AMF encoded
object, oops.
Once I discovered this error I was able to fix a
Henke!
Have we met on IRC ? I operate there as butter. Used to hit up actionscript and
papervison3d on freenode but it's been a while.
Ross P. Sclafani
Owner / Creative Director
Neuromantic Industries
http://www.neuromantic.com
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
Ross Sclafani skriver:
Henke!
Have we met on IRC ? I operate there as butter. Used to hit up actionscript
and papervison3d on freenode but it's been a while.
Quite likely, since I do hang on ##actionscript@Freenode all the time.
It must indeed have been quite a while, since I am afraid I
In a the client of a client/server AIR app I have:
function onSocketData(event:ProgressEvent) : void {
var result = _socket.readObject();
// do something with result
}
How can I be sure the whole object is available before I try to use it?
Things work as expected most of the time, but with
Hi,
Are you sure that this is not something server-side?
I have had similar problems which were compounded when using Wireless
connections - we traced the fault back to the server code giving up
filling the socket buffer when it got a buffer full event?
Apart from that you could use some
Basic TCP rules says that you are sending an octet stream.
All socket APIs are optimized for bulk access to avoid silly performance
issues due to lots of function calls (and possible mode switches).
This means that you MAY get more than one object in one go and that you
MAY get only a part of
I've not considered it may be a server issue. The server is also an AIR app -
looking at the documentation there doesn't seem to be any events related to
sending data over sockets - is it possible to tell if data was successfully
written to the socket?
On 2/15/12 11:29 AM, Glen Pike
I've been unsuccessful at finding an example of a functional AS app which uses
one of the second two approaches, I can only find broad descriptions of what
needs to happen.
It appears that Socket.bytesAvailable functions differently depending on the
version of AIR, either representing the
Mattheis, Erik (MIN-WSW) skriver:
If I have to do this without looking at functional examples, how would one
transmit a terminator byte or byte size while using Socket.writeObject()?
Write the object to a ByteArray, measure the size of that and send the
size of that before the contents of the
13 matches
Mail list logo
