Fragment data unmarshaling alignment
Brought to you by:
elliott_c2003
Menu
▾
▴
Hi,
I recently discovered a problem when using your package when unmarshaling multiple fragments.
It seems that your code unmarshals fragments as if they are one giant message, so it does not take fragment message restart into acount for its alignment of data types.
I had the following:
the first fragment ends in a string type size 23 of which the first 17 are send in this first fragment. In the second fragment the 6 following are added. When taking into consideration that the string length is a long and thus aligned at a factor 4 of the message, then alignment is necessary if the next data type is of type long (which is the case).
Your package then aligns 1 octet further (24%4 = 0) because you concatenate the message content.
However the server (of which I have no control) has added two stuffing octets, since that would align this data type in the fragment message itself.
Afterwards I took a look at the corba specs, and found the following in section 9.4.9:
*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.*
So it seems that there is someting wrong in your code.
If you need anything to help you address this issue, I can provide network captures, … Except for any changes on the server side. (Unless it is just plain wrong what it does, but then I have to contact its manufacturer,…)
many thanks in advance,
best regards,
A.D.
Hi,
Thanks for reporting this problem. I don't expect that the server is producing the wrong output, from what you quoted from the CORBA spec.
If you could provide a network capture, I may be able to figure out where my ORB is going wrong. Hopefully, I can find some time to look into the problem.
Thanks,
Chad
Hi,
Long latency on the reply (just received the email regarding you have answered…).
A capture is available for you at the following address:
Best regards,
A.D.
: http://users.telenet.be/erniedem/Capture_Fragments.pcap
Hi,
Seems that I have forgotten that the syntax of the message can be helpfull to see what happens.
I have uploaded an (not completely valid) IDL so you can see the basic structure of the messages:
best ragards,
A.D.
: http://users.pandora.be.erniedem/GetOutputSvcComponentBitrate.idl
Thanks for the additional information. I haven't had a lot of spare time lately. But when I get some, I'll take a look at the problem.
Thanks again,
Chad
Hi,
since it became somewhat urgent to have a fix for this problem, a collegue of mine has implemented a small fix.
You can find a small with files that have been changed.
The trace file and idl I provided you with before are now available in a . Note that this one is password protected. If you need this files, please send a small email to request the password.
best regards,
A.D.
: http://users.telenet.be/erniedem/IDL+trace.zip
: http://users.telenet.be/erniedem/opalpatch.zip
I'm really glad that your colleague was able to fix the issue. I'm also sorry that I wasn't able to find the time to work on this anymore than an initial investigation.
Does your colleague want credit for this when I integrate his/her changes? If so, please let me know.
Thanks,
Chad