Passing a structure through Sockets in C












45














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.










share|improve this question
























  • 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
















45














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.










share|improve this question
























  • 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














45












45








45


41





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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












7 Answers
7






active

oldest

votes


















66














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.






share|improve this answer



















  • 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



















7














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);





share|improve this answer





















  • 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



















6














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?






share|improve this answer

















  • 1




    That or XDR, which solved this problem decades ago.
    – Steve Emmerson
    Feb 15 '10 at 0:26



















4














There is no need to write own serialisation routines for short and long integer types - use htons()/htonl() POSIX functions.






share|improve this answer























  • @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



















1














Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.






share|improve this answer































    0














    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.






    share|improve this answer























    • 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



















    0














    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.






    share|improve this answer





















    • @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











    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    66














    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.






    share|improve this answer



















    • 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
















    66














    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.






    share|improve this answer



















    • 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














    66












    66








    66






    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.






    share|improve this answer














    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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














    • 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













    7














    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);





    share|improve this answer





















    • 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
















    7














    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);





    share|improve this answer





















    • 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














    7












    7








    7






    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);





    share|improve this answer












    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);






    share|improve this answer












    share|improve this answer



    share|improve this answer










    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


















    • 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











    6














    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?






    share|improve this answer

















    • 1




      That or XDR, which solved this problem decades ago.
      – Steve Emmerson
      Feb 15 '10 at 0:26
















    6














    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?






    share|improve this answer

















    • 1




      That or XDR, which solved this problem decades ago.
      – Steve Emmerson
      Feb 15 '10 at 0:26














    6












    6








    6






    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?






    share|improve this answer












    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?







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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














    • 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











    4














    There is no need to write own serialisation routines for short and long integer types - use htons()/htonl() POSIX functions.






    share|improve this answer























    • @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
















    4














    There is no need to write own serialisation routines for short and long integer types - use htons()/htonl() POSIX functions.






    share|improve this answer























    • @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














    4












    4








    4






    There is no need to write own serialisation routines for short and long integer types - use htons()/htonl() POSIX functions.






    share|improve this answer














    There is no need to write own serialisation routines for short and long integer types - use htons()/htonl() POSIX functions.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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


















    • @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











    1














    Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.






    share|improve this answer




























      1














      Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.






      share|improve this answer


























        1












        1








        1






        Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.






        share|improve this answer














        Serialization is a good idea. You can also use Wireshark to monitor the traffic and understand what is actually passed in the packets.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 13 at 21:03









        weteamsteve

        4910




        4910










        answered Oct 16 '09 at 10:05









        eyalm

        2,8001419




        2,8001419























            0














            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.






            share|improve this answer























            • 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
















            0














            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.






            share|improve this answer























            • 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














            0












            0








            0






            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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


















            • 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











            0














            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.






            share|improve this answer





















            • @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
















            0














            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.






            share|improve this answer





















            • @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














            0












            0








            0






            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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


















            • @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


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            鏡平學校

            ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

            Why https connections are so slow when debugging (stepping over) in Java?