Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 950 - GIOP 1.1 - Fragmented Messages
Summary: GIOP 1.1 - Fragmented Messages
Status: REOPENED
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 3.2
Hardware: All All
: P3 normal
Assignee: Mailinglist to track bugs
URL:
Depends on:
Blocks:
 
Reported: 2013-05-24 13:17 CEST by Christian Häßelbarth
Modified: 2013-08-21 08:04 CEST (History)
2 users (show)

See Also:


Attachments
original capture (111.80 KB, application/octet-stream)
2013-05-24 13:17 CEST, Christian Häßelbarth
Details
capture fixed (111.83 KB, application/octet-stream)
2013-05-24 13:18 CEST, Christian Häßelbarth
Details
original logfile (11.94 KB, application/octet-stream)
2013-05-24 13:18 CEST, Christian Häßelbarth
Details
logfile fixed (8.96 KB, application/octet-stream)
2013-05-24 13:18 CEST, Christian Häßelbarth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Häßelbarth 2013-05-24 13:17:07 CEST
Hi all, 

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? 

Best regards, 
Christian
Comment 1 Christian Häßelbarth 2013-05-24 13:17:46 CEST
Created attachment 412 [details]
original capture
Comment 2 Christian Häßelbarth 2013-05-24 13:18:12 CEST
Created attachment 413 [details]
capture fixed
Comment 3 Christian Häßelbarth 2013-05-24 13:18:32 CEST
Created attachment 414 [details]
original logfile
Comment 4 Christian Häßelbarth 2013-05-24 13:18:48 CEST
Created attachment 415 [details]
logfile fixed
Comment 5 Nick Cross 2013-05-24 14:24:29 CEST
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/
Comment 6 Christian Häßelbarth 2013-05-26 18:32:09 CEST
I just send a pull request against https://github.com/JacORB/JacORB/
Comment 7 Nick Cross 2013-06-01 10:21:41 CEST
I have commented on the pull request.
Comment 8 Nick Cross 2013-06-11 17:47:07 CEST
Merged pull request - thanks!
Comment 9 Sofie De Cooman 2013-07-04 18:12:10 CEST
Hi all, 

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?

Thanks
Comment 10 Nick Cross 2013-08-10 04:32:29 CEST
BZ950 : Revert 4d2cb9335fb3f5735b5bbc75133a4ccf10cfdffa / d608b9cd11a87856cfab07872bc23356ea20234d for JacORB 3.3
Comment 11 Christian Häßelbarth 2013-08-21 08:04:44 CEST
I'm still working on this issue.