views:

963

answers:

2

Using Action Script 3 in Flex Builder 3.

When handling a SOCKET_DATA event, I occasionally, seemingly at random, get an "Error #2030: End of file was encountered." when calling socket.readInt(). I'm confused as to what this error means, since I'm not reading a file? I'm a little unfamilier with sockets. Thanks.

+2  A: 

An end-of-file error typically means the other side of the socket has closed their connection, IIRC.

The reason it's end-of-file is that at a very low level within a program, a file on the disk and a socket are both represented with a number -- a file descriptor -- that the OS translates into the object representing a file or socket or pipe or whatever.

Usually, you can avoid this kind of error by checking if you just read in an EOF. If you did read an EOF, and you try reading from the socket/file again, then you will get an EOF error.


Update: According to the ActionScript 9.0 documentation, you do indeed get a close event if the other end closes the socket.

Mark Rushakoff
Thanks, should I get a SOCKET_CLOSE event or similar if the other side closes the connection?
AaronLS
good guess, but not true in the case of flash player ... see my answer ...
back2dos
+1  A: 

when reading off a socket, that is closed, you will get: Error #2002: Operation attempted on invalid socket.

end-of-file errors typically occur on any bytestreams, if you read more bytes than available ... this is the case for files, sockets, etc. ... in the case of flash, it occurs when reading from a Socket or a ByteArray and maybe even in other cases ...

TCP/IP is package based, but emulates a stream ... thus you can only read the data off the stream, that was already sent to you with TCP packages ... check Socket::bytesAvailable to find out, how many bytes are currently available ... always keep in mind, that the data you write to the socket in one operation, may arrive in multiple packages, each very probably causing flash player to trigger socketData events ...

back2dos
Just followup for anyone else with this issue. I think it is because I have been only checking that bytesAvailable is > 0, which I had seen from someone else's code, but then doing readInt which would be 4 bytes. So if there were only 1 to 3 bytes of data, readInt would hypothetically fail in some way.
AaronLS