Coke wrote:
Overhead on objectstreams? Sure, in comparison to datastreams which are essentially just byte arrays, but use of multiple sockets per client and gzip compression streams means your packets are still tiny, and it allows you to implement a fantastically secure and structured object oriented code design.
An uncompressed objectoutputstream running on a single threaded socket is insanely faster (we are talking lightening) than vb6's winsock implementation. Also, by using this method we can simply create a new instance of the object being sent, fire it through a static factory and actually reduce server-side overhead dramatically as objects are being instanciated, dealt with and disposed of bloody quickly.
After coding the entire networking backend both ways, the objectstream design model just has so many advantages and such a tiny speed difference I just have to conclude it is a better way of handling this kind of problem.
Also, datastreams are io blocking on the socket which is fucking mega bad news, object streams are not..
I'm not trying to flame you or anything, I genuinely went out and wanted to find the best possible way of writing the networking for a java powered mmo. Just sharing my experiences.
Objectstreams certainly offer a more structured approach. Sometimes I wonder if the structured approach is really worth the hassle. Do you have any code for an objectstream design? I'd really like to see it, I've been unable to find much information on this. I have done a lot of research on different design approaches, but good code isn't easily accessible.
The key word here is 'static factory', could you explain to me how your static factory works? Does each class sent over a network connection have to implement or extend some interface/abstract class? I was actually using
this design pattern for interpreting packet data, so I'm kinda going in the same direction and I may consider switching to an object stream.
I understand you aren't flaming, I've been searching for the same information.