|
Wow, thank you so much for your contribution! :)
I looked at your code. It looks OK. I'll merge this into the trunk after some optimization on object serialization. Thanks again! Trustin I checked the code again. It won't work if an object is splitted into multiple packets. We'll have to improve the implementation. But the ObjectInputStream itself is stream-based, so we need to introduce an additional field such as message length to suppress the interpretation until all data is received.
I see the problem. I took a look at xStream serialization framework and it looks very fine.
I only have a concern about how the serialization filter would work with UDP transport. If the xml stream it's breaked on multiple packets, with UDP there is no garanties that packets will be received in the correct order. One solution can be that, when using UDP, the stream would be breaked in the filter and every packet would be carrying a sequence number. Then when all packets will be received the stream will be de-serialized. What do you think? I reworked on the filter to resolve the issue with the stream being splitted in multiple packets. I'm dealing with the two different cases of TCP and UDP.
TCP is working fine. I've added a 4 bytes int containing the overall stream length at the beginning. Then the object is de-serialized when the entire-stream is received. The partial buffer is saved as an attribute session. UDP is more difficult. I've implemented a packet fragmentation method that splits the stream and send every packet with attached sequence number. The receiver will get the UDP packets in no particular order and can reconstruct the stream using the sequence number. Problems arise because I can't save the received packets as a session attribute. Every time messageReceived() is called on the filter, the session object is different. I thinked to use a message Id attached to every packet, and store them temporarely into a static Map instead of session. But then a new problem comes up: using session, all the saved data is cleared when a timeout event is fired. Using a static map, lost packets will remain there forever.. Any thoughs? Is Udp support important or can it be droppen? I believe it's important, at least for a completeness point of view.. Supporting TCP only is sufficient IMHO. We can later add another filter that emulates the behavior of TCP/IP using message ID. WDYT?
Matteo, it would be great if you can provide the updated version of SerializationFilter so I can accept your contribution. :)
I'm just taking a look at the new method that you added to ByteBuffer get/putObject that do the same I implemented in the filter. So I'm going to clean-up the filter and make it use the putObject().. and remove (for now) the code for UDP, that is broken..
I needed this filter immediately, so I implemented it by myself quickly. I'd like to compare with your implementation, Marten. Please review mine:
http://svn.apache.org/viewcvs?rev=349650&view=rev There was no objection on the implementation.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Object serialization filter
I think is really a nice idea to provide such a serialization file, so here's a quick implementation I made.
Attached there is the filter and a small test/example that does use it.
Please review.