Structure through sendto()

[ataanis]

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

 

[Kenneth Brody]

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:[email protected]>

 

[Walter Roberson]

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 .

 

[Malcolm]

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.

 

[Keith Thompson]

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

 

[Stephen Sprunk]

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


*** ***

 

[Walter Roberson]

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.

 

[Stephen Sprunk]

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?

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


*** ***