Sending a class using sockets

I am trying to get some information regarding how classes get defined and
handled in QNX, in comparison to other OSes. We currently have a problem in
this area, and it is only appearing in one of several OSes that we are
developing in – QNX.

At any rate, we are utilizing socket communications, and we are sending
information by transmitting a class across the wire. This works rather well
in Windows, VxWorks, and Linux, but on QNX it seems to work much
differently. When we print out all of the data from the class that we are
sending, on the other operating systems, there is 4 bytes of information at
the front of the socket message that seems to be related to the class
information – if we remove or re-arrange variables or methods within the
class, these numbers change. For the QNX system, these numbers seem to be
close to the end of the socket message, or between class and subclass
boundaries, perhaps. Whatever the case, we can communicate using sockets
within the context of the PC, but when we actually try to talk to another
box (PC, Linux or whatever), the comms fails because the data is not aligned
the same as the other three OSes, and the class information that is being
sent from another operating system is mis-interpreted as data.

Has anyone seen anything like this before, or know how to correct for this?

-Kevin

Myguess is that it has nothing to do with clases per se.

Take your class and dump the bytes in hex to the screen. Are they what you
expect? I’ll bet not. First thing to look at is the packing of your data.

Otherwise, post a simple class and the bytes that were dumped.
If the hex dump IS what you expect, receive it at the other end and dump
the same bytes and post them here.

“Kevin White” <kevin.w.white@lmco.com> wrote in message
news:bgdsok$r38$1@inn.qnx.com

I am trying to get some information regarding how classes get defined and
handled in QNX, in comparison to other OSes. We currently have a problem
in
this area, and it is only appearing in one of several OSes that we are
developing in – QNX.

At any rate, we are utilizing socket communications, and we are sending
information by transmitting a class across the wire. This works rather
well
in Windows, VxWorks, and Linux, but on QNX it seems to work much
differently. When we print out all of the data from the class that we are
sending, on the other operating systems, there is 4 bytes of information
at
the front of the socket message that seems to be related to the class
information – if we remove or re-arrange variables or methods within the
class, these numbers change. For the QNX system, these numbers seem to be
close to the end of the socket message, or between class and subclass
boundaries, perhaps. Whatever the case, we can communicate using sockets
within the context of the PC, but when we actually try to talk to another
box (PC, Linux or whatever), the comms fails because the data is not
aligned
the same as the other three OSes, and the class information that is being
sent from another operating system is mis-interpreted as data.

Has anyone seen anything like this before, or know how to correct for
this?

-Kevin

On a more general note, is there a commonly accepted, portable way to send
structures and classes through a socket? Is it best to convert it to a char
array first, then build it at the receiving end according to the endianness
of the receiver? This would be one way to avoid compiler-dependent packing
pitfalls.

“Bill Caroselli” <QTPS@Earthlink.net> wrote in message
news:bge4do$344$1@inn.qnx.com

Myguess is that it has nothing to do with clases per se.

Take your class and dump the bytes in hex to the screen. Are they what
you
expect? I’ll bet not. First thing to look at is the packing of your
data.

Otherwise, post a simple class and the bytes that were dumped.
If the hex dump IS what you expect, receive it at the other end and dump
the same bytes and post them here.

“Kevin White” <> kevin.w.white@lmco.com> > wrote in message
news:bgdsok$r38$> 1@inn.qnx.com> …
I am trying to get some information regarding how classes get defined
and
handled in QNX, in comparison to other OSes. We currently have a
problem
in
this area, and it is only appearing in one of several OSes that we are
developing in – QNX.

At any rate, we are utilizing socket communications, and we are sending
information by transmitting a class across the wire. This works rather
well
in Windows, VxWorks, and Linux, but on QNX it seems to work much
differently. When we print out all of the data from the class that we
are
sending, on the other operating systems, there is 4 bytes of information
at
the front of the socket message that seems to be related to the class
information – if we remove or re-arrange variables or methods within
the
class, these numbers change. For the QNX system, these numbers seem to
be
close to the end of the socket message, or between class and subclass
boundaries, perhaps. Whatever the case, we can communicate using
sockets
within the context of the PC, but when we actually try to talk to
another
box (PC, Linux or whatever), the comms fails because the data is not
aligned
the same as the other three OSes, and the class information that is
being
sent from another operating system is mis-interpreted as data.

Has anyone seen anything like this before, or know how to correct for
this?

-Kevin

\

JV wrote:

On a more general note, is there a commonly accepted, portable way to send
structures and classes through a socket? Is it best to convert it to a char
array first, then build it at the receiving end according to the endianness
of the receiver? This would be one way to avoid compiler-dependent packing
pitfalls.

XDR. An author for C++ users journal wrote a series of articles on how to
do this portably. If you google for XDR you should get plenty of links. Of
course, you can’t actually send the vtab across the wire, you can only
serialize the data from a class, send the serialized data across the wire,
and then de-serialize the data into an identical class on the remote
machine; but you can do this portably.

Rennie

Bill,

When we started looking into the details of the problem, we printed out the
messages in hex, and tried to find all of the class contents that we knew
about for a couple of the shorter messages. We decoded everything except
for the first two bytes on the Win32/Linux systems. On the QNX system, we
noticed the same effect, but the unknown bytes were towards the end of the
message, actually it appeared to be between the base message, and the
inherited message data elements.

We also changed the structure of the message by adding, removing, and
re-arranging the elements. All of which affected the values in the
positions of the message that I described previously. Another note of
interest, is that these messages, which are new’ed an destroyed many times
per second, always contain the same values within those positions, from
message type to message type during a given trial run. This was true for
all of the OSes we tested this on.

-Kevin

Bill Caroselli <QTPS@Earthlink.net> wrote in message
news:bge4do$344$1@inn.qnx.com

Myguess is that it has nothing to do with clases per se.

Take your class and dump the bytes in hex to the screen. Are they what
you
expect? I’ll bet not. First thing to look at is the packing of your
data.

Otherwise, post a simple class and the bytes that were dumped.
If the hex dump IS what you expect, receive it at the other end and dump
the same bytes and post them here.

“Kevin White” <> kevin.w.white@lmco.com> > wrote in message
news:bgdsok$r38$> 1@inn.qnx.com> …
I am trying to get some information regarding how classes get defined
and
handled in QNX, in comparison to other OSes. We currently have a
problem
in
this area, and it is only appearing in one of several OSes that we are
developing in – QNX.

At any rate, we are utilizing socket communications, and we are sending
information by transmitting a class across the wire. This works rather
well
in Windows, VxWorks, and Linux, but on QNX it seems to work much
differently. When we print out all of the data from the class that we
are
sending, on the other operating systems, there is 4 bytes of information
at
the front of the socket message that seems to be related to the class
information – if we remove or re-arrange variables or methods within
the
class, these numbers change. For the QNX system, these numbers seem to
be
close to the end of the socket message, or between class and subclass
boundaries, perhaps. Whatever the case, we can communicate using
sockets
within the context of the PC, but when we actually try to talk to
another
box (PC, Linux or whatever), the comms fails because the data is not
aligned
the same as the other three OSes, and the class information that is
being
sent from another operating system is mis-interpreted as data.

Has anyone seen anything like this before, or know how to correct for
this?

-Kevin

\

The only two things I can think of are these:

  1. Do any of these classes have any virtual methods? This is a RBT (Really Bad Thing). I would derive a functioning class from a message struct where the message struct is just data.
  2. Are your structs/classes packed?
    I think you want to use:
    #pragma pack(1)
    Otherwise the compiler gets to stick padding anywhere into the struct it wants to. Obviously, if you have to pack your structs on one system then you should pack them on all OSs.

Short of these two issues, I don’t have a clue where the extra bytes are coming from.


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net


Kevin White <kevin.w.white@lmco.com> wrote:
KW > Bill,

KW > When we started looking into the details of the problem, we printed out the
KW > messages in hex, and tried to find all of the class contents that we knew
KW > about for a couple of the shorter messages. We decoded everything except
KW > for the first two bytes on the Win32/Linux systems. On the QNX system, we
KW > noticed the same effect, but the unknown bytes were towards the end of the
KW > message, actually it appeared to be between the base message, and the
KW > inherited message data elements.

KW > We also changed the structure of the message by adding, removing, and
KW > re-arranging the elements. All of which affected the values in the
KW > positions of the message that I described previously. Another note of
KW > interest, is that these messages, which are new’ed an destroyed many times
KW > per second, always contain the same values within those positions, from
KW > message type to message type during a given trial run. This was true for
KW > all of the OSes we tested this on.

KW > -Kevin

KW > Bill Caroselli <QTPS@Earthlink.net> wrote in message
KW > news:bge4do$344$1@inn.qnx.com

Myguess is that it has nothing to do with clases per se.

Take your class and dump the bytes in hex to the screen. Are they what
KW > you
expect? I’ll bet not. First thing to look at is the packing of your
KW > data.

Otherwise, post a simple class and the bytes that were dumped.
If the hex dump IS what you expect, receive it at the other end and dump
the same bytes and post them here.