Structure through sendto()

Discussion in 'C Programming' started by ataanis@gmail.com, May 26, 2006.

  1. Guest

    I'm currently using the function:
    sendto(sockfd, message, strlen(message), 0,&client_addr, addr_size)

    to sending a message back to a client, and I was wondering if there was
    a way of sending a structure instead, so that I can open it in the
    client side?
    Thanks
    , May 26, 2006
    #1
    1. Advertising

  2. wrote:
    >
    > I'm currently using the function:
    > sendto(sockfd, message, strlen(message), 0,&client_addr, addr_size)
    >
    > to sending a message back to a client, and I was wondering if there was
    > a way of sending a structure instead, so that I can open it in the
    > client side?


    Well, sendto() isn't part of Standard C, but treating this the same
    as "can I fwrite() to a file, take that file to another computer,
    and then fread() it there"...

    Yes, sort of, maybe.

    If (and this is a big "if") the other computer uses the internal
    representation of all struct members, has the same byte order and
    structure padding, and the stuct contents are useful as-is (for
    example, no pointers), then sending the struct as-is to the other
    computer may "work".

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, May 26, 2006
    #2
    1. Advertising

  3. In article <>,
    <> wrote:

    >I'm currently using the function:
    > sendto(sockfd, message, strlen(message), 0,&client_addr, addr_size)


    >to sending a message back to a client, and I was wondering if there was
    >a way of sending a structure instead, so that I can open it in the
    >client side?


    sentto() is not part of the C standard, so the question is probably
    more appropriate to the unix programming newsgroup.


    Generally speaking, a structure is a platform-dependant assembly
    of the representation of values. If the client at the other end has
    exactly the same representation of values and exactly the same padding
    then you can move the bytes corresponding to the structure into
    a buffer that is properly aligned for the platform, and then cast the
    buffer pointer to become a structure pointer, and then use that.
    Of course if the structure includes pointers, then the transported
    pointers are unlikely to be valid at the other end.

    If the other end does not have *exactly* the same representation of
    values, then on one side or the other you would have to munge the values
    to get them into a form that the other side can understand. If you
    do not know in advance all the details of the other end, then the easiest
    way to do this is to convert the structure values into a portable form,
    send that portable form, and have the other end convert to an appropriate
    local form.

    Probably your operating system offers some useful library routines that are
    part of the POSIX standard but not the C standard. I suggest you
    look up xdr .
    --
    Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
    Walter Roberson, May 26, 2006
    #3
  4. Malcolm Guest

    <> wrote in message
    news:...
    > I'm currently using the function:
    > sendto(sockfd, message, strlen(message), 0,&client_addr, addr_size)
    >
    > to sending a message back to a client, and I was wondering if there was
    > a way of sending a structure instead, so that I can open it in the
    > client side?
    > Thanks
    >

    Write a function

    void *serialise(struct mystruct *ptr, int *N)

    and another

    struct mystruct *retrieve(void *serial)


    This is sometimes impossible if the structure contains pointers to external
    data. In that case you need to rethink your design.
    The functions should be entirely portable and assume ASCII and 8-bit bytes.
    So convert floating point numbers to text, send integers in big endian, and
    so on. Then you know it will survive the passage ove the network.
    --
    Buy my book 12 Common Atheist Arguments (refuted)
    $1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
    Malcolm, May 28, 2006
    #4
  5. "Malcolm" <> writes:
    [...]
    > Write a function
    >
    > void *serialise(struct mystruct *ptr, int *N)
    >
    > and another
    >
    > struct mystruct *retrieve(void *serial)
    >
    >
    > This is sometimes impossible if the structure contains pointers to external
    > data. In that case you need to rethink your design.
    > The functions should be entirely portable and assume ASCII and 8-bit bytes.
    > So convert floating point numbers to text, send integers in big endian, and
    > so on. Then you know it will survive the passage ove the network.


    If it assumes ASCII and 8-bit bytes, it's not entirely portable
    (though it may well be portable enough for your purposes).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, May 28, 2006
    #5
  6. "Keith Thompson" <> wrote in message
    news:...
    > "Malcolm" <> writes:
    > [...]
    >> Write a function
    >>
    >> void *serialise(struct mystruct *ptr, int *N)
    >>
    >> and another
    >>
    >> struct mystruct *retrieve(void *serial)
    >>
    >>
    >> This is sometimes impossible if the structure contains pointers to
    >> external data. In that case you need to rethink your design.
    >> The functions should be entirely portable and assume ASCII and
    >> 8-bit bytes. So convert floating point numbers to text, send
    >> integers in big endian, and so on. Then you know it will survive
    >> the passage ove the network.

    >
    > If it assumes ASCII and 8-bit bytes, it's not entirely portable
    > (though it may well be portable enough for your purposes).


    Given the prototype he gave for sendto(), it's virtually certain that he's
    referring to the POSIX (and Berkeley sockets) function of that name. Since
    POSIX requires 8-bit bytes (and the Internet is defined in terms of octets),
    that's not likely to be a problem. POSIX allows many character encodings
    (unfortunately), but AFAIK all of the allowed ones are supersets of ASCII.

    This still leaves problems with different sizes of types, endianness,
    alignment/padding, and embedded pointers. The short answer, just like for
    writing complex data types to files, is to convert everything to a specific
    representation for communication between different systems.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin


    *** Posted via a free Usenet account from http://www.teranews.com ***
    Stephen Sprunk, May 29, 2006
    #6
  7. In article <447a8ed5$0$24294$>,
    Stephen Sprunk <> wrote:

    >Given the prototype he gave for sendto(), it's virtually certain that he's
    >referring to the POSIX (and Berkeley sockets) function of that name. Since
    >POSIX requires 8-bit bytes (and the Internet is defined in terms of octets),
    >that's not likely to be a problem. POSIX allows many character encodings
    >(unfortunately), but AFAIK all of the allowed ones are supersets of ASCII.


    Citations?

    ISO/IEC 9945-1: 1990 (aka IEEE Std 1003.1-1990 aka POSIX.1)

    section 2.2.2.8 defines character as "a sequence of one or more
    bytes representing a single graphic symbol", and specifically notes
    the definition to be equivilent to C's multibyte character.

    section 2.71 imports byte from ISO C without any restriction to
    8 bit bytes.

    Section 2.2.2.60 refers to the "portable filename character set"
    (upper and lower case english letters together with the 10 digits, period,
    dash, and underscore), but B.2.2.2 "General Terms" indicates,

    portable filename character set: The encoding of this character set
    is not specified -- specifically, ASCII is not required. But the
    implementation must provide a unique character code for each of
    the printable graphics specified by POSIX.1.

    8.1.2.2 (Description of setlocale) indicates that,
    The value "C" for locale specifies the minimal environment for
    C-Language translation.

    There's nothing there that would prevent the local "C" locale from using
    EBCDIC as the encoding, nor that would prevent bytes from being 9 or
    16 bits or whatever.


    >(and the Internet is defined in terms of octets),


    No it isn't. In particular, ethernet frames are defined in terms
    of bits. Look, for example, at IEEE 802's use of preamble (some of it
    is allowed to be eaten or distorted along the way, as long as enough
    is left to establish signal synchronization). See also how the
    intraframe gap is defined and notice that the standards allow for it to
    shrink.

    If "the Internet" was defined in terms of octets, then a received packet
    would have to start on a synchronized octet boundary, which is not the
    case: many internet transports are asynchronous, with the initial
    field of the preamble being used to sychronize the data clocks.
    --
    There are some ideas so wrong that only a very intelligent person
    could believe in them. -- George Orwell
    Walter Roberson, May 29, 2006
    #7
  8. "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:e5fae8$dur$...
    > In article <447a8ed5$0$24294$>,
    > Stephen Sprunk <> wrote:
    >>Given the prototype he gave for sendto(), it's virtually certain that he's
    >>referring to the POSIX (and Berkeley sockets) function of that name.
    >>Since POSIX requires 8-bit bytes (and the Internet is defined in terms
    >>of octets), that's not likely to be a problem. POSIX allows many
    >>character encodings (unfortunately), but AFAIK all of the allowed
    >>ones are supersets of ASCII.

    >
    > Citations?
    >
    > ISO/IEC 9945-1: 1990 (aka IEEE Std 1003.1-1990 aka POSIX.1)

    ....
    > There's nothing there that would prevent the local "C" locale from using
    > EBCDIC as the encoding, nor that would prevent bytes from being 9 or
    > 16 bits or whatever.


    I'd swear I've seen that stated, unchallenged, several times on clc; I never
    looked at the spec myself. Perhaps it's assumed because all known
    implementations of POSIX use 8-bit bytes and a superset of ASCII?

    >>(and the Internet is defined in terms of octets),

    >
    > No it isn't. In particular, ethernet frames are defined in terms
    > of bits. Look, for example, at IEEE 802's use of preamble (some of it
    > is allowed to be eaten or distorted along the way, as long as enough
    > is left to establish signal synchronization). See also how the
    > intraframe gap is defined and notice that the standards allow for it to
    > shrink.


    I said the Internet, not Ethernet. The IEEE has nothing to do with the
    Internet; that's the IETF's bailiwick. IP packets are defined as a sequence
    of octets, and TCP sockets are defined to transport streams of octets.
    While I'm sure it's possible to implement TCP/IP on top of systems or link
    layers that have bytes of more than 8 bits, it's not easy. Ditto for
    EBCDIC.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin


    *** Posted via a free Usenet account from http://www.teranews.com ***
    Stephen Sprunk, May 29, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Intaek Lim

    sendto() failed (10040)

    Intaek Lim, Mar 30, 2005, in forum: C++
    Replies:
    1
    Views:
    2,236
    Victor Bazarov
    Mar 30, 2005
  2. B.r.K.o.N.j.A.

    help with sendto (linux)

    B.r.K.o.N.j.A., Dec 11, 2003, in forum: C Programming
    Replies:
    4
    Views:
    2,281
    B.r.K.o.N.j.A.
    Dec 12, 2003
  3. BlueJ
    Replies:
    6
    Views:
    393
    Ben Bacarisse
    Oct 19, 2007
  4. Henry 'Pi' James

    asyncore's lack of sendto(), recvfrom()

    Henry 'Pi' James, Jul 11, 2009, in forum: Python
    Replies:
    0
    Views:
    430
    Henry 'Pi' James
    Jul 11, 2009
  5. MRAB
    Replies:
    0
    Views:
    452
Loading...

Share This Page