Re: [lwip-users] douts in UDP of Lwip

[Bikram Chatterjee]

Thanks David for the detail on endian-ness. I omitted those details in my example assuming that everybody follows these standards. But yes it is always worth mentioning, just in case... :)

__Bikram

On Tue, Feb 26, 2008 at 4:40 PM, David Empson <address@hidden> wrote:

An issue to watch out for when sending integer data is your byte ordering.
Both sender and receiver must agree in advance that integer data will be
sent either high order byte first or low order byte first. If both
processors are the same "endianness" then this will happen automatically,
but if one is big endian and the other is little endian, then either the
sender or the receiver will have to swap the bytes around. If you might port
either the sender or receiver to a different processor in future, it would
be a good idea to define this clearly so that you don't have problems later.
You might even want to write the code in a portable manner now so that it
will be handled correctly when the code is ported.

Standard TCP/IP protocols typically use "network byte order" for multi-byte
fields, which is defined as high order byte first. There are standard
functions like htons() and ntohs() which convert between network and
host-specific byte order (for short integers, i.e. 16-bit). If you are on a
big-endian processor, they do nothing, but on a little-endian processor they
will swap the bytes over. For 32-bit integers, you can use htonl() and
ntohl().

If your UDP data is in a proprietary format and both ends agree in advance,
you could send data low order byte first, but you might want to stick to the
convention of network byte order and send the data high order byte first.

If you intend to send more complex data structures (e.g. a struct rather
than a simple array of integers), then it gets more complicated, because the
memory layout of a structure may have padding/alignment bytes inserted by
the compiler. This padding varies between processor architectures, and can
vary between different compilers on the same processor or by changing build
options for the same compiler. Again, you need to clearly define what the
structure looks like as it appears on the network, and ensure that you are
sending the data in that format, without any internal padding. This may
require carefully designing your structures to avoid internal padding, or
turning on compiler options to force packing of the structure, or separating
out individual fields and copying them one at a time.

If you also need to deal with byte ordering issues, then it is probably
easier to break down the structure and copy it between the struct variable
and the transmit/receive data buffer one field at a time.

"Bikram Chatterjee" <address@hidden> wrote:
> The BSD socket layer of lwip works identical to that of Linux. A code
> as below should work:
>
> int a=10;
> struct sockaddr *to; // Destination address
> socklen_t to_len = sizeof(struct sockaddr);
> ...
> sendto(sock, &a, sizeof(a), 0, to, to_len);
>
> __Bikram
>
> On Mon, Feb 25, 2008 at 7:19 PM, dinesh babu <address@hidden>
> wrote:
>> can we send only the string data in the call sento. is it possible to
>> send the interger data. can anyone give me the code for this (UDP
>> purpose)

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users