Hi Mika,
I have noticed, that if in GIOP, there is servicecontextlist > 0 (or 1
?) and lenght of context_data = 0 (seqlen_cd), data is shown wrongly.
All the number of sequence are not going through, so ethereal (giop
plugins) starts to open data from wrong place.
Example: ServiceContextList
SequenceLenght:3
First context_data is empty=0
--> second and third are not going through.
So you are saying that the first of the 3 Service Contexts contains just
a Service Id and no context data. If this is ok according to the Corba
Specs, then it is certainly wrong to return from the decoding function
there, leaving the rest of the service contexts in the list unprocessed.
What I did, I took two lines away from packet-giop.c v.1.57
lines from 4798:
if(seqlen_cd == 0)
return;
--->
// if(seqlen_cd == 0)
// return;
And it open data correctly.
What do you think about this ?
What problems this could cause ?
I think it may be better to do a "continue" instead of
commenting it out in order to save some function calls with
a length of zero. Also, it shouldn't put the context_data
into the protocol tree.
But maybe in your case the seqlen_cd is being decoded incorrectly?
The way it is computed depends on CONTEXT_DATA_IS_ENCAPSULATED.
The default is that CONTEXT_DATA_IS_ENCAPSULATED is 0
and seqlen_cd is decoded as an unsigned long. Maybe in your case it
is really encapsulated? See the comment from Frank Singelton in the code:
/*
* This affects how we handle context_data inside ServiceContext structs.
* According to CORBA 2.4.2, Context data is encapsulated in octet
sequences,
* but so far I haven't seen the that on the wire. But, maybe its me -- FS
*
*/
#define CONTEXT_DATA_IS_ENCAPSULATED 0
I will have a look at the Corba Specs and see if I can understand it.
Bernd