topic Re: Problem in data transfer in Operating System - HP-UX

Problem in data transfer

Santha — Sun, 13 Nov 2005 02:29:54 GMT

Hello everybody,
I am sending a 512 byte data packet which is of type unsigned short from client to HP-UX server through socket communication.The sever is receiving the data packet but when we display the buffer in HP-UX server it is containing garbage values but not the exact values from client.What is the problem?.Please help me out.Advanced Thanks for reply.

Re: Problem in data transfer

Steven E. Protter — Sun, 13 Nov 2005 02:49:12 GMT

Suggest you use tcpdump or ethereal to analyze the traffic. Perhaps post the output if you've already done so.

Not a lot to go on now. Many possible causes.

SEP

Re: Problem in data transfer

Arunvijai_4 — Sun, 13 Nov 2005 06:52:43 GMT

Hello, How do you store your data in the buffer cache ? Are there any memory corruption happening ? Run the server end in GDB and get the values. Also, you can use tcpdump (cli) or Ethereal (X11) as SEP suggested. You can download them from,

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1111

-Arun

Re: Problem in data transfer

Hein van den Heuvel — Sun, 13 Nov 2005 13:23:15 GMT

Since you mention "unsigned short"... could the be a confusion on little endian vs big-endian? That would make a 1, show as 256, 2 as 512, 3 as 768 and so on.
Basically.. do the bytes in he shorts appear as they should, but in the wrong place within the short?
Dump the bytestream through od to verify, or just attempt a to manually byteswap a few values.

hth,
Hein.

Re: Problem in data transfer

A. Clay Stephenson — Sun, 13 Nov 2005 15:38:43 GMT

With so little to go on, it's difficult to be sure but in any event when sending any data that might have to cross platforms it's always a good idea to go through the XDR (eXternal Data Representation) routines on both ends to avoid just this kind of problem.

Re: Problem in data transfer

Santha — Mon, 14 Nov 2005 04:53:06 GMT

Hello Everybody,
Thanks for the reply.I am facing same problem what Hein van den has mentioned.If i send a value of 3 it is displaying as 768.Can you give more information on how to solve this solution.Advaced thanks for the reply.

Re: Problem in data transfer

Hein van den Heuvel — Mon, 14 Nov 2005 06:49:30 GMT

read all about it: http://en.wikipedia.org/wiki/Little_endian
and google, and computer textbooks, and...

Best thing is probably to NOT send your data to an other system in binary format, but using some transportable protocol as mentioned before. Depending on the volume of data, with respect to the byte/secons as well as the number of fields you may just want to send an ascii representation of the number in fiexed fields or seperated format.

Regards,
Hein.

Re: Problem in data transfer

rick jones — Mon, 14 Nov 2005 12:57:48 GMT

Something like Stevens' et al's Unix Network Programming would probably be a good reference to have. As suggested, you _probably_ have an issue with endianess between two systems. All HP-UX systems are "big endian" and many clients (eg x86 boxes) are "little endian"

Also, you should be careful with how your client may or may not "pack" data in things like structures - there may be padding in the structures and if you simply send from &structure, sizeof(structure) you will send the padding as well, which your remote system will try to interpret as real data.

Re: Problem in data transfer

A. Clay Stephenson — Mon, 14 Nov 2005 18:01:30 GMT

As I mentioned before, XDR is the "correct" solution to your problem. This will allow you to transfer complex data in a completely machine-independent format. Man xdr for details. You other option is to convert verything to text and use string to numeric conversion routines on the receiving end but XDR is the cleaner approach.

Re: Problem in data transfer

A. Clay Stephenson — Mon, 14 Nov 2005 18:20:28 GMT

... and the bad news about "fixing" endian problems is that as soon as you get it working on client platform "A", you just broke "B". Floating point representation is even worse. XDR completely and truly fixes your problem.