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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
