So basically im writing a client-server multiplayer game. I have a SeverCommunicationThread that creates a gameThread if he receives a RequestForGame creates a gameThread.
There's another possibility that I ran across where if you implement a custom deserialization routine for a class by adding this method:
private void readObject( ObjectInputStream objectInputStream ) throws IOException
then objectInputStream.defaultReadObject() must be called and called before any further reads of the input stream to properly initialise the object.
I missed this and despite the object returning without an exception being thrown it was the next read of the object stream that confusingly raised the invalid type code exception.
This link provides further information on the process: http://osdir.com/ml/java.sun.jini/2003-10/msg00204.html.
java.io.StreamCorruptedException: invalid type code: 00
I recently ran into this problem, not doing what OP did though. Did a quick google search and didn't find anything that was too helpful and because I think I solved it I am making a comment with my solution.
TLDR: Don't have multiple threads write to the same output stream at same time (instead take turns). Will cause issues for when client side tries to read the data. Solution is putting a lock on the writing to output.
I am doing something very similar to OP, making a multiplayer (client-server model) game. I have a thread like OP that is listening for traffic. What was happening, in my server side was that server had multiple threads that were writing to a client's stream at the same time (didn't think it was possible, game was semi turn base). Client side thread that was reading the incoming traffic was throwing this exception. To solve this I basically put a lock on the part that wrote to the client's stream (on server side) so each thread in server side would have to obtain the lock before writing to the stream.
If ObjectInputStream
is constructed only once and then just passed a reference of it to the other Thread then simply enclose the access of this object inside synchronized
block to make sure that only one thread can access this object at a time.
Whenever you are reading from ObjectInputStream
just access it inside the synchronized
block if it is shared between multiple threads.
Sample code:(do it for all the occurrences of readObject()
)
...
String nickname = null;
synchronized (inFromClient) {
nickname = (String) inFromClient.readObject();
}
This can also happen if the JVM reading the serialized object does not have the correct class/jar files for the object. This usually results in a ClassNotFoundException
, but if you have different jar/class versions and the serialVersionUID
was not changed between versions, a StreamCorruptedException
is produced. (This exception may also be possible if there is a class name conflict. e.g.: a jar containing a different class with the same full class name, though they probably also need the same serilVersionUID
).
Check that the client side has the correct versions of jars and class files.
I too had this exception. It occurred because I used two threads for Server class and Client class. I used one thread for object sending and receiving thing. Then it was ok. This is easy way to solve the problem if you are not familiar with synchronized
.
This problem can happen if you
ObjectInputStream
or ObjectOutputStream
over the same socket instead of using the same ones for the life of the socket;