pitfalls of struct to char* and back

[kevincw01]

I've got this homework assignment where I need to send some data over
a simulated network. Don't worry, I dont want someone to write the
code for me, just wondering if there are problems with the logic of my
solution.

The network API accepts a char* with a maximum of 40 bytes. I can
send and receive char* strings(under 40) all day long without
problem.
Then I created a struct of size 20 bytes:
struct RPCMsgType {
int transaction;

//client side
RPCMsgType rm;
strcpy(rm.name,"testLock");
rm.transaction = 9;
printf("size=%d\n",sizeof(rm));
char *RPCArray = (char*)&rm;
nc.sendMessage(0,0,RPCArray); //network client abstraction that does
a send to the rcvr

If I cast back to the struct on the client side, I have no problems.
However when it's received on server side and I try the same thing, I
get nonsense data:

//network receiver
postOffice->Receive(mbPort, &inPktHdr, &inMailHdr, buffer);
char *buffer = new char[sizeof(RPCMsgType)];
RPCMsgType *rm = (RPCMsgType*)buffer;
printf("Got \"%d\" from %d:%d\n",rm-

transaction,inPktHdr.from,inMailHdr.from);

fflush(stdout);

This printf always prints some really large number for rm->transaction
when it should be 9.

Obviously there is a big unknown to you, the reader, since there is
this network simulation black box but I'm just wondering if you could
understand why this might be happening, say from personal experience
in a related field? Some of you may recognize the network API and
realize the it is from the NACHOS simulator.

Thanks for any insight, pointers, suggestions, etc...

-Kevin

 

[Jim Langston]

I've got this homework assignment where I need to send some data over
a simulated network. Don't worry, I dont want someone to write the
code for me, just wondering if there are problems with the logic of my
solution.

The network API accepts a char* with a maximum of 40 bytes. I can
send and receive char* strings(under 40) all day long without
problem.
Then I created a struct of size 20 bytes:
struct RPCMsgType {
int transaction;

//client side
RPCMsgType rm;
strcpy(rm.name,"testLock");
rm.transaction = 9;
printf("size=%d\n",sizeof(rm));
char *RPCArray = (char*)&rm;
nc.sendMessage(0,0,RPCArray); //network client abstraction that does
a send to the rcvr

This call, I notice, does not receive the size of the data to send. So most
likely you are using strlen or such and determining the length by the
placement of the first null character. That will work for actual string
data, but not binary data. The size of an int is dependant on your machine,
lets go with an example of a machine with a int size of 4, that stores LSBF
(Least signifiacnt byte first).

Your value of 9 then is stored in 4 bytes, with the least significant byte
set to 9, the rest set to 0. (There could be other arrangments, we're just
using this as an example).

Now, the char* will point to the byte with the 9 in it. Your send will see
the 9 then a 0, so thinks that there is a data length of 1, when it is
actually 4. So it will send 1 byte.

The receiving end receives presumedly until it receives a null also, so it
receives 1 byte.

Now you try to take this data and put it back into an int. The least
significant byte will contain the 9. But what of the other 3 bytes? They
will contain... anything. Whatever happens to be in memory past the data.
Which is why it's showing you the value as some large number, random data.

What you need to do for your send is also pass the length of the data to
send, in this case sizeof rm.

Now, if you don't want to have to calculate the size for strings, just
binary data, then you can do something like, if I pass a 0, then I'll use
strlen to figure out the length, otherwise I"ll use the passed in length.

If I cast back to the struct on the client side, I have no problems.
However when it's received on server side and I try the same thing, I
get nonsense data:

//network receiver
postOffice->Receive(mbPort, &inPktHdr, &inMailHdr, buffer);
char *buffer = new char[sizeof(RPCMsgType)];
RPCMsgType *rm = (RPCMsgType*)buffer;
printf("Got \"%d\" from %d:%d\n",rm-

transaction,inPktHdr.from,inMailHdr.from);

fflush(stdout);

This printf always prints some really large number for rm->transaction
when it should be 9.

Obviously there is a big unknown to you, the reader, since there is
this network simulation black box but I'm just wondering if you could
understand why this might be happening, say from personal experience
in a related field? Some of you may recognize the network API and
realize the it is from the NACHOS simulator.

Thanks for any insight, pointers, suggestions, etc...

-Kevin

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I've got this homework assignment where I need to send some data over
a simulated network. Don't worry, I dont want someone to write the
code for me, just wondering if there are problems with the logic of my
solution.

The network API accepts a char* with a maximum of 40 bytes. I can
send and receive char* strings(under 40) all day long without
problem.
Then I created a struct of size 20 bytes:
struct RPCMsgType {
int transaction;

I assume that the rest of the struct looks like this:
char name[16]; // Assuming 4 bytes for an int

Note that if you have char* name instead you'll get problems since the
string is not part of the struct, but I figure you'd noticed that when
you perform the strcpy() below.

//client side
RPCMsgType rm;
strcpy(rm.name,"testLock");
rm.transaction = 9;
printf("size=%d\n",sizeof(rm));
char *RPCArray = (char*)&rm;
nc.sendMessage(0,0,RPCArray); //network client abstraction that does
a send to the rcvr

If I cast back to the struct on the client side, I have no problems.
However when it's received on server side and I try the same thing, I
get nonsense data:

//network receiver
postOffice->Receive(mbPort, &inPktHdr, &inMailHdr, buffer);
char *buffer = new char[sizeof(RPCMsgType)];

Are you sure that you have not swapped the above two lines?

RPCMsgType *rm = (RPCMsgType*)buffer;
printf("Got \"%d\" from %d:%d\n",rm-
fflush(stdout);

As Jim Langstom pointed out it might be a problem with using strlen when
sending the data, if it's you who wrote the sendMessage() method then I
would suggest that you rewrite it to accept a RPCMsgType instead of a
char* as argument, you could probably do the same for Receive().

 

[kevincw01]

//network receiver

postOffice->Receive(mbPort, &inPktHdr, &inMailHdr, buffer);
char *buffer = new char[sizeof(RPCMsgType)];

Are you sure that you have not swapped the above two lines?

Sorry, yes, the char memory allocation is before the receive.

I can't rewrite the network API but Jim is right. The strlen was
interpretting the size wrong(well right if it were a char string but
its not). I changed it to sizeof() and now it works! Thanks guys.

 

[kevincw01]

//network receiver
postOffice->Receive(mbPort, &inPktHdr, &inMailHdr, buffer);
char *buffer = new char[sizeof(RPCMsgType)];

Are you sure that you have not swapped the above two lines?

Sorry, yes, the char memory allocation is before the receive.

I can't rewrite the network API but Jim is right. The strlen was
interpretting the size wrong(well right if it were a char string but
its not). I changed it to sizeof() and now it works! Thanks guys.

Woops, looks like its *almost working*. I can print out the int but
when I print the char[10] i only get the first letter. The struct got
cut off last time so here it is again:
struct RPCMsgType {
int transaction;
char name[10];
int lockID;
};

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

//network receiver
postOffice->Receive(mbPort, &inPktHdr, &inMailHdr, buffer);
char *buffer = new char[sizeof(RPCMsgType)];
Are you sure that you have not swapped the above two lines?

Sorry, yes, the char memory allocation is before the receive.

I can't rewrite the network API but Jim is right. The strlen was
interpretting the size wrong(well right if it were a char string but
its not). I changed it to sizeof() and now it works! Thanks guys.

Woops, looks like its *almost working*. I can print out the int but
when I print the char[10] i only get the first letter. The struct got
cut off last time so here it is again:
struct RPCMsgType {
int transaction;
char name[10];
int lockID;

};

Since the size of RPCMsgType is fixed (18 bytes or so) I don't quite
see why you bother with the size, it is after all known. So send all
the bytes in the struct and expect to receive as many too.

PS, you can probably shrink the RPCMsgType to 18 bytes (if it's 20) by
putting the declaration of lockID above the declaration of transaction
since the compiler will probably place lockID on a 4-byte boundary,
which will be 2 bytes after the end of name.