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
>



-- 
Bikram Chatterjee
Senior Engineer
Alumnus Software Limited
Kolkata