we are using the JacORB lib for IIOP communication with a Cisco DCM (Multiplexer for DVB-Streams). The DCM sends fragemented IIOP Packets and uses GIOP 1.1
I've read in the source file org/jacorb/orb/giop/GIOPConnection.java that fragmented messages with GIOP 1.1 are not supported.
I extended and changed org/jacorb/orb/giop/GIOPConnection.java in order to support fragmentet GIOP 1.1 messages. Since the request id is not included in GIOP 1.1 packets I saved the request id from the previous reply message. I'm using the saved request id for the following GIOP 1.1 fragmented messages.
I attached two wireshark capture files one with, one without my fixes and two JacORB log files.
Note: It seems to be a bug in wireshark that a request id is displayed in a GIOP 1.1 packet.
How should I post my code for review? As a file, text or patch?
Created attachment 412 [details]
Created attachment 413 [details]
Created attachment 414 [details]
Created attachment 415 [details]
That would be great thanks. Either a plain text patch file here or you could send a pull request against https://github.com/JacORB/JacORB/
I just send a pull request against https://github.com/JacORB/JacORB/
I have commented on the pull request.
Merged pull request - thanks!
We tried out the GIOP 1.1 fragmentation, but ran into org.omg.CORBA.MARSHAL / org.omg.CORBA.BAD_PARAM exceptions.
It looks like there is no handling for the fact that in GIOP 1.1, the data in a fragment is marshaled with alignment relative to its position in the fragment, not relative to its position in the whole unfragmented message.
Currently in org.jacorb.orb.CDRInputStream, the alignment does seem to be done relative to the position in the whole unfragmented message (the buffer member seems to contain the whole unfragmented message).
As a consequence, it's possible that the wrong data is read.
The individual fragments (or at least their sizes) don't seem to be available anymore in CDRInputStream, which makes it not so straightforward to fix?
Probably additional handling would be needed in org.jacorb.orb.CDROutputStream as well?
Could my understanding be correct?
BZ950 : Revert 4d2cb9335fb3f5735b5bbc75133a4ccf10cfdffa / d608b9cd11a87856cfab07872bc23356ea20234d for JacORB 3.3
I'm still working on this issue.