Passing a structure through Sockets in C
I am trying to pass whole structure from client to server or vice-versa. Let us assume my structure as follows
struct temp {
int a;
char b;
}
I am using sendto and sending the address of the structure variable and receiving it on the other side using the recvfrom function. But I am not able to get the original data sent on the receiving end. In sendto function I am saving the received data into variable of type struct temp.
n = sendto(sock, &pkt, sizeof(struct temp), 0, &server, length);
n = recvfrom(sock, &pkt, sizeof(struct temp), 0, (struct sockaddr *)&from,&fromlen);
Where pkt is the variable of type struct temp.
Eventhough I am receiving 8bytes of data but if I try to print it is simply showing garbage values. Any help for a fix on it ?
NOTE: No third party Libraries have to be used.
EDIT1: I am really new to this serialization concept .. But without doing serialization cant I send a structure via sockets ?
EDIT2: When I try to send a string or an integer variable using the sendto and recvfrom functions I am receiving the data properly at receiver end. Why not in the case of a structure? If I don't have to use serializing function then should I send each and every member of the structure individually? This really is not a suitable solution since if there are 'n' number of members then there are 'n' number of lines of code added just to send or receive data.
c sockets recv sendto
add a comment |
I am trying to pass whole structure from client to server or vice-versa. Let us assume my structure as follows
struct temp {
int a;
char b;
}
I am using sendto and sending the address of the structure variable and receiving it on the other side using the recvfrom function. But I am not able to get the original data sent on the receiving end. In sendto function I am saving the received data into variable of type struct temp.
n = sendto(sock, &pkt, sizeof(struct temp), 0, &server, length);
n = recvfrom(sock, &pkt, sizeof(struct temp), 0, (struct sockaddr *)&from,&fromlen);
Where pkt is the variable of type struct temp.
Eventhough I am receiving 8bytes of data but if I try to print it is simply showing garbage values. Any help for a fix on it ?
NOTE: No third party Libraries have to be used.
EDIT1: I am really new to this serialization concept .. But without doing serialization cant I send a structure via sockets ?
EDIT2: When I try to send a string or an integer variable using the sendto and recvfrom functions I am receiving the data properly at receiver end. Why not in the case of a structure? If I don't have to use serializing function then should I send each and every member of the structure individually? This really is not a suitable solution since if there are 'n' number of members then there are 'n' number of lines of code added just to send or receive data.
c sockets recv sendto
Can you post your sending/receiving code ?
– Brian Agnew
Oct 16 '09 at 9:52
1
Why are you reverting my edits to correct the weird double question marks?
– unwind
Oct 16 '09 at 12:07
1
Don't use structs as network protocols. Use network protocols as network protocols. Design your protocol, in octets, and write yourself a library to send and receive it. Or use an existing one, such as DML, XDR, ... Using structs introduces at least six dependencies you may not even be aware of, and causes further problems like this one.
– user207421
Jul 11 '14 at 21:34
@EJP - I agree with you
– codingfreak
Mar 12 '15 at 5:11
add a comment |
I am trying to pass whole structure from client to server or vice-versa. Let us assume my structure as follows
struct temp {
int a;
char b;
}
I am using sendto and sending the address of the structure variable and receiving it on the other side using the recvfrom function. But I am not able to get the original data sent on the receiving end. In sendto function I am saving the received data into variable of type struct temp.
n = sendto(sock, &pkt, sizeof(struct temp), 0, &server, length);
n = recvfrom(sock, &pkt, sizeof(struct temp), 0, (struct sockaddr *)&from,&fromlen);
Where pkt is the variable of type struct temp.
Eventhough I am receiving 8bytes of data but if I try to print it is simply showing garbage values. Any help for a fix on it ?
NOTE: No third party Libraries have to be used.
EDIT1: I am really new to this serialization concept .. But without doing serialization cant I send a structure via sockets ?
EDIT2: When I try to send a string or an integer variable using the sendto and recvfrom functions I am receiving the data properly at receiver end. Why not in the case of a structure? If I don't have to use serializing function then should I send each and every member of the structure individually? This really is not a suitable solution since if there are 'n' number of members then there are 'n' number of lines of code added just to send or receive data.
c sockets recv sendto
I am trying to pass whole structure from client to server or vice-versa. Let us assume my structure as follows
struct temp {
int a;
char b;
}
I am using sendto and sending the address of the structure variable and receiving it on the other side using the recvfrom function. But I am not able to get the original data sent on the receiving end. In sendto function I am saving the received data into variable of type struct temp.
n = sendto(sock, &pkt, sizeof(struct temp), 0, &server, length);
n = recvfrom(sock, &pkt, sizeof(struct temp), 0, (struct sockaddr *)&from,&fromlen);
Where pkt is the variable of type struct temp.
Eventhough I am receiving 8bytes of data but if I try to print it is simply showing garbage values. Any help for a fix on it ?
NOTE: No third party Libraries have to be used.
EDIT1: I am really new to this serialization concept .. But without doing serialization cant I send a structure via sockets ?
EDIT2: When I try to send a string or an integer variable using the sendto and recvfrom functions I am receiving the data properly at receiver end. Why not in the case of a structure? If I don't have to use serializing function then should I send each and every member of the structure individually? This really is not a suitable solution since if there are 'n' number of members then there are 'n' number of lines of code added just to send or receive data.
c sockets recv sendto
c sockets recv sendto
edited Oct 20 '09 at 8:19
asked Oct 16 '09 at 9:50
codingfreak
1,90193855
1,90193855
Can you post your sending/receiving code ?
– Brian Agnew
Oct 16 '09 at 9:52
1
Why are you reverting my edits to correct the weird double question marks?
– unwind
Oct 16 '09 at 12:07
1
Don't use structs as network protocols. Use network protocols as network protocols. Design your protocol, in octets, and write yourself a library to send and receive it. Or use an existing one, such as DML, XDR, ... Using structs introduces at least six dependencies you may not even be aware of, and causes further problems like this one.
– user207421
Jul 11 '14 at 21:34
@EJP - I agree with you
– codingfreak
Mar 12 '15 at 5:11
add a comment |
Can you post your sending/receiving code ?
– Brian Agnew
Oct 16 '09 at 9:52
1
Why are you reverting my edits to correct the weird double question marks?
– unwind
Oct 16 '09 at 12:07
1
Don't use structs as network protocols. Use network protocols as network protocols. Design your protocol, in octets, and write yourself a library to send and receive it. Or use an existing one, such as DML, XDR, ... Using structs introduces at least six dependencies you may not even be aware of, and causes further problems like this one.
– user207421
Jul 11 '14 at 21:34
@EJP - I agree with you
– codingfreak
Mar 12 '15 at 5:11
Can you post your sending/receiving code ?
– Brian Agnew
Oct 16 '09 at 9:52
Can you post your sending/receiving code ?
– Brian Agnew
Oct 16 '09 at 9:52
1
1
Why are you reverting my edits to correct the weird double question marks?
– unwind
Oct 16 '09 at 12:07
Why are you reverting my edits to correct the weird double question marks?
– unwind
Oct 16 '09 at 12:07
1
1
Don't use structs as network protocols. Use network protocols as network protocols. Design your protocol, in octets, and write yourself a library to send and receive it. Or use an existing one, such as DML, XDR, ... Using structs introduces at least six dependencies you may not even be aware of, and causes further problems like this one.
– user207421
Jul 11 '14 at 21:34
Don't use structs as network protocols. Use network protocols as network protocols. Design your protocol, in octets, and write yourself a library to send and receive it. Or use an existing one, such as DML, XDR, ... Using structs introduces at least six dependencies you may not even be aware of, and causes further problems like this one.
– user207421
Jul 11 '14 at 21:34
@EJP - I agree with you
– codingfreak
Mar 12 '15 at 5:11
@EJP - I agree with you
– codingfreak
Mar 12 '15 at 5:11
add a comment |
7 Answers
7
active
oldest
votes
This is a very bad idea. Binary data should always be sent in a way that:
- Handles different endianness
- Handles different padding
- Handles differences in the byte-sizes of intrinsic types
Don't ever write a whole struct in a binary way, not to a file, not to a socket.
Always write each field separately, and read them the same way.
You need to have functions like
unsigned char * serialize_int(unsigned char *buffer, int value)
{
/* Write big-endian int value into buffer; assumes 32-bit int and 8-bit char. */
buffer[0] = value >> 24;
buffer[1] = value >> 16;
buffer[2] = value >> 8;
buffer[3] = value;
return buffer + 4;
}
unsigned char * serialize_char(unsigned char *buffer, char value)
{
buffer[0] = value;
return buffer + 1;
}
unsigned char * serialize_temp(unsigned char *buffer, struct temp *value)
{
buffer = serialize_int(buffer, value->a);
buffer = serialize_char(buffer, value->b);
return buffer;
}
unsigned char * deserialize_int(unsigned char *buffer, int *value);
Or the equivalent, there are of course several ways to set this up with regards to buffer management and so on. Then you need to do the higher-level functions that serialize/deserialize entire structs.
This assumes serializing is done to/from buffers, which means the serialization doesn't need to know if the final destination is a file or a socket. It also means you pay some memory overhead, but it's generally a good design for performance reasons (you don't want to do a write() of each value to the socket).
Once you have the above, here's how you could serialize and transmit a structure instance:
int send_temp(int socket, const struct sockaddr *dest, socklen_t dlen,
const struct temp *temp)
{
unsigned char buffer[32], *ptr;
ptr = serialize_temp(buffer, temp);
return sendto(socket, buffer, ptr - buffer, 0, dest, dlen) == ptr - buffer;
}
A few points to note about the above:
- The struct to send is first serialized, field by field, into
buffer
. - The serialization routine returns a pointer to the next free byte in the buffer, which we use to compute how many bytes it serialized to
- Obviously my example serialization routines don't protect against buffer overflow.
- Return value is 1 if the
sendto()
call succeeded, else it will be 0.
3
And in this case,int
can have different sizes on the different machines as well.
– Douglas Leeder
Oct 16 '09 at 9:54
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
|
show 12 more comments
Using the 'pragma' pack option did solved my problem but I am not sure if it has any dependencies ??
#pragma pack(1) // this helps to pack the struct to 5-bytes
struct packet {
int i;
char j;
};
#pragma pack(0) // turn packing off
Then the following lines of code worked out fine without any problem
n = sendto(sock,&pkt,sizeof(struct packet),0,&server,length);
n = recvfrom(sock, &pkt, sizeof(struct packet), 0, (struct sockaddr *)&from, &fromlen);
can some explain this more?
– devin
Feb 18 '10 at 3:09
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
2
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
add a comment |
If you don't want to write the serialisation code yourself, find a proper serialisation framework, and use that.
Maybe Google's protocol buffers would be possible?
1
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
add a comment |
There is no need to write own serialisation routines for short
and long
integer types - use htons()
/htonl()
POSIX functions.
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
1
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
|
show 1 more comment
Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.
add a comment |
Instead of serialising and depending on 3rd party libraries its easy to come up with a primitive protocol using tag, length and value.
Tag: 32 bit value identifying the field
Length: 32 bit value specifying the length in bytes of the field
Value: the field
Concatenate as required. Use enums for the tags. And use network byte order...
Easy to encode, easy to decode.
Also if you use TCP remember it is a stream of data so if you send e.g. 3 packets you will not necessarily receive 3 packets. They maybe be "merged" into a stream depending on nodelay/nagel algorithm amongst other things and you may get them all in one recv... You need to delimit the data for example using RFC1006.
UDP is easier, you'll receive a distinct packet for each packet sent, but its a lot less secure.
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
|
show 1 more comment
If the format of the data you want to transfer is very simple then converting to and from an ANSI string is simple and portable.
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1577161%2fpassing-a-structure-through-sockets-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a very bad idea. Binary data should always be sent in a way that:
- Handles different endianness
- Handles different padding
- Handles differences in the byte-sizes of intrinsic types
Don't ever write a whole struct in a binary way, not to a file, not to a socket.
Always write each field separately, and read them the same way.
You need to have functions like
unsigned char * serialize_int(unsigned char *buffer, int value)
{
/* Write big-endian int value into buffer; assumes 32-bit int and 8-bit char. */
buffer[0] = value >> 24;
buffer[1] = value >> 16;
buffer[2] = value >> 8;
buffer[3] = value;
return buffer + 4;
}
unsigned char * serialize_char(unsigned char *buffer, char value)
{
buffer[0] = value;
return buffer + 1;
}
unsigned char * serialize_temp(unsigned char *buffer, struct temp *value)
{
buffer = serialize_int(buffer, value->a);
buffer = serialize_char(buffer, value->b);
return buffer;
}
unsigned char * deserialize_int(unsigned char *buffer, int *value);
Or the equivalent, there are of course several ways to set this up with regards to buffer management and so on. Then you need to do the higher-level functions that serialize/deserialize entire structs.
This assumes serializing is done to/from buffers, which means the serialization doesn't need to know if the final destination is a file or a socket. It also means you pay some memory overhead, but it's generally a good design for performance reasons (you don't want to do a write() of each value to the socket).
Once you have the above, here's how you could serialize and transmit a structure instance:
int send_temp(int socket, const struct sockaddr *dest, socklen_t dlen,
const struct temp *temp)
{
unsigned char buffer[32], *ptr;
ptr = serialize_temp(buffer, temp);
return sendto(socket, buffer, ptr - buffer, 0, dest, dlen) == ptr - buffer;
}
A few points to note about the above:
- The struct to send is first serialized, field by field, into
buffer
. - The serialization routine returns a pointer to the next free byte in the buffer, which we use to compute how many bytes it serialized to
- Obviously my example serialization routines don't protect against buffer overflow.
- Return value is 1 if the
sendto()
call succeeded, else it will be 0.
3
And in this case,int
can have different sizes on the different machines as well.
– Douglas Leeder
Oct 16 '09 at 9:54
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
|
show 12 more comments
This is a very bad idea. Binary data should always be sent in a way that:
- Handles different endianness
- Handles different padding
- Handles differences in the byte-sizes of intrinsic types
Don't ever write a whole struct in a binary way, not to a file, not to a socket.
Always write each field separately, and read them the same way.
You need to have functions like
unsigned char * serialize_int(unsigned char *buffer, int value)
{
/* Write big-endian int value into buffer; assumes 32-bit int and 8-bit char. */
buffer[0] = value >> 24;
buffer[1] = value >> 16;
buffer[2] = value >> 8;
buffer[3] = value;
return buffer + 4;
}
unsigned char * serialize_char(unsigned char *buffer, char value)
{
buffer[0] = value;
return buffer + 1;
}
unsigned char * serialize_temp(unsigned char *buffer, struct temp *value)
{
buffer = serialize_int(buffer, value->a);
buffer = serialize_char(buffer, value->b);
return buffer;
}
unsigned char * deserialize_int(unsigned char *buffer, int *value);
Or the equivalent, there are of course several ways to set this up with regards to buffer management and so on. Then you need to do the higher-level functions that serialize/deserialize entire structs.
This assumes serializing is done to/from buffers, which means the serialization doesn't need to know if the final destination is a file or a socket. It also means you pay some memory overhead, but it's generally a good design for performance reasons (you don't want to do a write() of each value to the socket).
Once you have the above, here's how you could serialize and transmit a structure instance:
int send_temp(int socket, const struct sockaddr *dest, socklen_t dlen,
const struct temp *temp)
{
unsigned char buffer[32], *ptr;
ptr = serialize_temp(buffer, temp);
return sendto(socket, buffer, ptr - buffer, 0, dest, dlen) == ptr - buffer;
}
A few points to note about the above:
- The struct to send is first serialized, field by field, into
buffer
. - The serialization routine returns a pointer to the next free byte in the buffer, which we use to compute how many bytes it serialized to
- Obviously my example serialization routines don't protect against buffer overflow.
- Return value is 1 if the
sendto()
call succeeded, else it will be 0.
3
And in this case,int
can have different sizes on the different machines as well.
– Douglas Leeder
Oct 16 '09 at 9:54
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
|
show 12 more comments
This is a very bad idea. Binary data should always be sent in a way that:
- Handles different endianness
- Handles different padding
- Handles differences in the byte-sizes of intrinsic types
Don't ever write a whole struct in a binary way, not to a file, not to a socket.
Always write each field separately, and read them the same way.
You need to have functions like
unsigned char * serialize_int(unsigned char *buffer, int value)
{
/* Write big-endian int value into buffer; assumes 32-bit int and 8-bit char. */
buffer[0] = value >> 24;
buffer[1] = value >> 16;
buffer[2] = value >> 8;
buffer[3] = value;
return buffer + 4;
}
unsigned char * serialize_char(unsigned char *buffer, char value)
{
buffer[0] = value;
return buffer + 1;
}
unsigned char * serialize_temp(unsigned char *buffer, struct temp *value)
{
buffer = serialize_int(buffer, value->a);
buffer = serialize_char(buffer, value->b);
return buffer;
}
unsigned char * deserialize_int(unsigned char *buffer, int *value);
Or the equivalent, there are of course several ways to set this up with regards to buffer management and so on. Then you need to do the higher-level functions that serialize/deserialize entire structs.
This assumes serializing is done to/from buffers, which means the serialization doesn't need to know if the final destination is a file or a socket. It also means you pay some memory overhead, but it's generally a good design for performance reasons (you don't want to do a write() of each value to the socket).
Once you have the above, here's how you could serialize and transmit a structure instance:
int send_temp(int socket, const struct sockaddr *dest, socklen_t dlen,
const struct temp *temp)
{
unsigned char buffer[32], *ptr;
ptr = serialize_temp(buffer, temp);
return sendto(socket, buffer, ptr - buffer, 0, dest, dlen) == ptr - buffer;
}
A few points to note about the above:
- The struct to send is first serialized, field by field, into
buffer
. - The serialization routine returns a pointer to the next free byte in the buffer, which we use to compute how many bytes it serialized to
- Obviously my example serialization routines don't protect against buffer overflow.
- Return value is 1 if the
sendto()
call succeeded, else it will be 0.
This is a very bad idea. Binary data should always be sent in a way that:
- Handles different endianness
- Handles different padding
- Handles differences in the byte-sizes of intrinsic types
Don't ever write a whole struct in a binary way, not to a file, not to a socket.
Always write each field separately, and read them the same way.
You need to have functions like
unsigned char * serialize_int(unsigned char *buffer, int value)
{
/* Write big-endian int value into buffer; assumes 32-bit int and 8-bit char. */
buffer[0] = value >> 24;
buffer[1] = value >> 16;
buffer[2] = value >> 8;
buffer[3] = value;
return buffer + 4;
}
unsigned char * serialize_char(unsigned char *buffer, char value)
{
buffer[0] = value;
return buffer + 1;
}
unsigned char * serialize_temp(unsigned char *buffer, struct temp *value)
{
buffer = serialize_int(buffer, value->a);
buffer = serialize_char(buffer, value->b);
return buffer;
}
unsigned char * deserialize_int(unsigned char *buffer, int *value);
Or the equivalent, there are of course several ways to set this up with regards to buffer management and so on. Then you need to do the higher-level functions that serialize/deserialize entire structs.
This assumes serializing is done to/from buffers, which means the serialization doesn't need to know if the final destination is a file or a socket. It also means you pay some memory overhead, but it's generally a good design for performance reasons (you don't want to do a write() of each value to the socket).
Once you have the above, here's how you could serialize and transmit a structure instance:
int send_temp(int socket, const struct sockaddr *dest, socklen_t dlen,
const struct temp *temp)
{
unsigned char buffer[32], *ptr;
ptr = serialize_temp(buffer, temp);
return sendto(socket, buffer, ptr - buffer, 0, dest, dlen) == ptr - buffer;
}
A few points to note about the above:
- The struct to send is first serialized, field by field, into
buffer
. - The serialization routine returns a pointer to the next free byte in the buffer, which we use to compute how many bytes it serialized to
- Obviously my example serialization routines don't protect against buffer overflow.
- Return value is 1 if the
sendto()
call succeeded, else it will be 0.
edited Jul 18 '17 at 18:20
McAngus
866622
866622
answered Oct 16 '09 at 9:52
unwind
318k52394526
318k52394526
3
And in this case,int
can have different sizes on the different machines as well.
– Douglas Leeder
Oct 16 '09 at 9:54
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
|
show 12 more comments
3
And in this case,int
can have different sizes on the different machines as well.
– Douglas Leeder
Oct 16 '09 at 9:54
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
3
3
And in this case,
int
can have different sizes on the different machines as well.– Douglas Leeder
Oct 16 '09 at 9:54
And in this case,
int
can have different sizes on the different machines as well.– Douglas Leeder
Oct 16 '09 at 9:54
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@Douglas: Absolutely true, and added the list. Thanks!
– unwind
Oct 16 '09 at 9:57
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@unwind - Are serialize_int and deserialize_int are standard functions ??
– codingfreak
Oct 16 '09 at 10:00
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@codingfreak: No, you need to define them to do the kind of serialization you need.
– unwind
Oct 16 '09 at 10:03
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
@unwind - I did not get you ... ?? Should I send only individual members rather than sending whole structure at once via socket ??
– codingfreak
Oct 16 '09 at 10:05
|
show 12 more comments
Using the 'pragma' pack option did solved my problem but I am not sure if it has any dependencies ??
#pragma pack(1) // this helps to pack the struct to 5-bytes
struct packet {
int i;
char j;
};
#pragma pack(0) // turn packing off
Then the following lines of code worked out fine without any problem
n = sendto(sock,&pkt,sizeof(struct packet),0,&server,length);
n = recvfrom(sock, &pkt, sizeof(struct packet), 0, (struct sockaddr *)&from, &fromlen);
can some explain this more?
– devin
Feb 18 '10 at 3:09
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
2
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
add a comment |
Using the 'pragma' pack option did solved my problem but I am not sure if it has any dependencies ??
#pragma pack(1) // this helps to pack the struct to 5-bytes
struct packet {
int i;
char j;
};
#pragma pack(0) // turn packing off
Then the following lines of code worked out fine without any problem
n = sendto(sock,&pkt,sizeof(struct packet),0,&server,length);
n = recvfrom(sock, &pkt, sizeof(struct packet), 0, (struct sockaddr *)&from, &fromlen);
can some explain this more?
– devin
Feb 18 '10 at 3:09
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
2
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
add a comment |
Using the 'pragma' pack option did solved my problem but I am not sure if it has any dependencies ??
#pragma pack(1) // this helps to pack the struct to 5-bytes
struct packet {
int i;
char j;
};
#pragma pack(0) // turn packing off
Then the following lines of code worked out fine without any problem
n = sendto(sock,&pkt,sizeof(struct packet),0,&server,length);
n = recvfrom(sock, &pkt, sizeof(struct packet), 0, (struct sockaddr *)&from, &fromlen);
Using the 'pragma' pack option did solved my problem but I am not sure if it has any dependencies ??
#pragma pack(1) // this helps to pack the struct to 5-bytes
struct packet {
int i;
char j;
};
#pragma pack(0) // turn packing off
Then the following lines of code worked out fine without any problem
n = sendto(sock,&pkt,sizeof(struct packet),0,&server,length);
n = recvfrom(sock, &pkt, sizeof(struct packet), 0, (struct sockaddr *)&from, &fromlen);
answered Oct 20 '09 at 10:23
codingfreak
1,90193855
1,90193855
can some explain this more?
– devin
Feb 18 '10 at 3:09
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
2
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
add a comment |
can some explain this more?
– devin
Feb 18 '10 at 3:09
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
2
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
can some explain this more?
– devin
Feb 18 '10 at 3:09
can some explain this more?
– devin
Feb 18 '10 at 3:09
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
@devin - cplusplus.com/forum/general/14659 or gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
– jschmier
Mar 6 '10 at 0:26
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
that's it.... but what if there are bit fields??
– gp.
Dec 25 '12 at 9:01
2
2
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@codingfreak : you probably tested in the same machine. did you try from bigendian machine to littleendian machine and viceverse ?
– resultsway
Mar 26 '13 at 17:20
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
@purpletech - Hmm that might be an issue
– codingfreak
Mar 12 '15 at 5:10
add a comment |
If you don't want to write the serialisation code yourself, find a proper serialisation framework, and use that.
Maybe Google's protocol buffers would be possible?
1
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
add a comment |
If you don't want to write the serialisation code yourself, find a proper serialisation framework, and use that.
Maybe Google's protocol buffers would be possible?
1
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
add a comment |
If you don't want to write the serialisation code yourself, find a proper serialisation framework, and use that.
Maybe Google's protocol buffers would be possible?
If you don't want to write the serialisation code yourself, find a proper serialisation framework, and use that.
Maybe Google's protocol buffers would be possible?
answered Oct 16 '09 at 10:12
Douglas Leeder
43.5k877120
43.5k877120
1
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
add a comment |
1
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
1
1
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
That or XDR, which solved this problem decades ago.
– Steve Emmerson
Feb 15 '10 at 0:26
add a comment |
There is no need to write own serialisation routines for short
and long
integer types - use htons()
/htonl()
POSIX functions.
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
1
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
|
show 1 more comment
There is no need to write own serialisation routines for short
and long
integer types - use htons()
/htonl()
POSIX functions.
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
1
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
|
show 1 more comment
There is no need to write own serialisation routines for short
and long
integer types - use htons()
/htonl()
POSIX functions.
There is no need to write own serialisation routines for short
and long
integer types - use htons()
/htonl()
POSIX functions.
edited Oct 20 '09 at 12:13
answered Oct 16 '09 at 11:26
qrdl
27.2k114576
27.2k114576
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
1
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
|
show 1 more comment
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
1
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl - How should I use htonl for a structure ?? htonl(pkt); ???
– codingfreak
Oct 16 '09 at 11:36
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@qrdl: So does my function, as documented. It will always serialize to big-endian. You can of course use htonX()/ntohX() functions too, but this tried to illustrate a more general approach.
– unwind
Oct 16 '09 at 11:47
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@codingfreak I didn't say to use it on structure. It is proper way to serialise short or long integers, that's it
– qrdl
Oct 16 '09 at 12:50
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
@qrdl - But my question is how to send a structure via sockets ... even without using htons()/htonl() functions I am able to send and receive data properly using sendto() and recvfrom() functions .....
– codingfreak
Oct 20 '09 at 8:13
1
1
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
@unwind My bad. I'm sorry, I keep forgetting that shift is endianness-aware. I'll change my post
– qrdl
Oct 20 '09 at 12:11
|
show 1 more comment
Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.
add a comment |
Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.
add a comment |
Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.
Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.
edited Nov 13 at 21:03
weteamsteve
4910
4910
answered Oct 16 '09 at 10:05
eyalm
2,8001419
2,8001419
add a comment |
add a comment |
Instead of serialising and depending on 3rd party libraries its easy to come up with a primitive protocol using tag, length and value.
Tag: 32 bit value identifying the field
Length: 32 bit value specifying the length in bytes of the field
Value: the field
Concatenate as required. Use enums for the tags. And use network byte order...
Easy to encode, easy to decode.
Also if you use TCP remember it is a stream of data so if you send e.g. 3 packets you will not necessarily receive 3 packets. They maybe be "merged" into a stream depending on nodelay/nagel algorithm amongst other things and you may get them all in one recv... You need to delimit the data for example using RFC1006.
UDP is easier, you'll receive a distinct packet for each packet sent, but its a lot less secure.
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
|
show 1 more comment
Instead of serialising and depending on 3rd party libraries its easy to come up with a primitive protocol using tag, length and value.
Tag: 32 bit value identifying the field
Length: 32 bit value specifying the length in bytes of the field
Value: the field
Concatenate as required. Use enums for the tags. And use network byte order...
Easy to encode, easy to decode.
Also if you use TCP remember it is a stream of data so if you send e.g. 3 packets you will not necessarily receive 3 packets. They maybe be "merged" into a stream depending on nodelay/nagel algorithm amongst other things and you may get them all in one recv... You need to delimit the data for example using RFC1006.
UDP is easier, you'll receive a distinct packet for each packet sent, but its a lot less secure.
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
|
show 1 more comment
Instead of serialising and depending on 3rd party libraries its easy to come up with a primitive protocol using tag, length and value.
Tag: 32 bit value identifying the field
Length: 32 bit value specifying the length in bytes of the field
Value: the field
Concatenate as required. Use enums for the tags. And use network byte order...
Easy to encode, easy to decode.
Also if you use TCP remember it is a stream of data so if you send e.g. 3 packets you will not necessarily receive 3 packets. They maybe be "merged" into a stream depending on nodelay/nagel algorithm amongst other things and you may get them all in one recv... You need to delimit the data for example using RFC1006.
UDP is easier, you'll receive a distinct packet for each packet sent, but its a lot less secure.
Instead of serialising and depending on 3rd party libraries its easy to come up with a primitive protocol using tag, length and value.
Tag: 32 bit value identifying the field
Length: 32 bit value specifying the length in bytes of the field
Value: the field
Concatenate as required. Use enums for the tags. And use network byte order...
Easy to encode, easy to decode.
Also if you use TCP remember it is a stream of data so if you send e.g. 3 packets you will not necessarily receive 3 packets. They maybe be "merged" into a stream depending on nodelay/nagel algorithm amongst other things and you may get them all in one recv... You need to delimit the data for example using RFC1006.
UDP is easier, you'll receive a distinct packet for each packet sent, but its a lot less secure.
edited Oct 16 '09 at 11:40
answered Oct 16 '09 at 11:35
hplbsh
2,21822233
2,21822233
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
|
show 1 more comment
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
At present I am using recvfrom and sendto which are generally used in the case of UDP communication ....
– codingfreak
Oct 16 '09 at 11:37
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Yes, it'll be fine for loopback or reliable connections.
– hplbsh
Oct 16 '09 at 11:42
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
Is'nt there any other solution other than this TAGGING stuff ???
– codingfreak
Oct 16 '09 at 11:43
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
There are many. Google Protocols, Apache Thrift, ASN.1, CSN.1, JSON, XML ... Depending on your application you could get away with what you are doing and it'll work just fine... its just not very robust!
– hplbsh
Oct 16 '09 at 11:49
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
I already mentioned in the Question... no third party stuff just libc libraries ...
– codingfreak
Oct 16 '09 at 12:01
|
show 1 more comment
If the format of the data you want to transfer is very simple then converting to and from an ANSI string is simple and portable.
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
add a comment |
If the format of the data you want to transfer is very simple then converting to and from an ANSI string is simple and portable.
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
add a comment |
If the format of the data you want to transfer is very simple then converting to and from an ANSI string is simple and portable.
If the format of the data you want to transfer is very simple then converting to and from an ANSI string is simple and portable.
answered Oct 16 '09 at 12:10
the_mandrill
22.7k45185
22.7k45185
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
add a comment |
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
@mandrill - Let use suppose it is a complex one ---- a generic solution would be the best answer if possible ... ??
– codingfreak
Oct 16 '09 at 12:35
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
If the format is more complex then I defer to the superior solutions given elsewhere in this thread! Alternatively serialise to something more generic such as XML or a SOAP-like wrapper.
– the_mandrill
Oct 16 '09 at 15:28
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
Ultimately the aim is to serialise your data in a portable manner, so conversion to and from a string is portable, simple and readable. It may not be the most secure or efficient method, but it doesn't require any 3rd party libraries.
– the_mandrill
Oct 16 '09 at 15:31
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
How do I re-convert back the string into the data that cane be placed into a struct .... it would be more complex I feel so ??
– codingfreak
Oct 17 '09 at 13:45
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
To re-convert the string back into data you'd have to parse the string, using things like atof(), atoi(), sscanf(), etc. (well maybe not sscanf(), it's dangerous). You're right, parsing the string can get complex for non-simple data. I'd recommend using a 3rd party serialization library instead.
– Jeremy Friesner
Oct 17 '09 at 17:14
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1577161%2fpassing-a-structure-through-sockets-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Can you post your sending/receiving code ?
– Brian Agnew
Oct 16 '09 at 9:52
1
Why are you reverting my edits to correct the weird double question marks?
– unwind
Oct 16 '09 at 12:07
1
Don't use structs as network protocols. Use network protocols as network protocols. Design your protocol, in octets, and write yourself a library to send and receive it. Or use an existing one, such as DML, XDR, ... Using structs introduces at least six dependencies you may not even be aware of, and causes further problems like this one.
– user207421
Jul 11 '14 at 21:34
@EJP - I agree with you
– codingfreak
Mar 12 '15 at 5:11