data is transfered over IP from a 32-bit machine to a 64-bit machine (or vice versa). Since the data will be transfered in network byte order there will be no problem during the transfer. Question: Will there be any problem when the data reaches the receiving end? What should be taken care of to avoid any problems, if there are any?
A:
Not an issue... data is generally stored (and transfered) as bytes, the size of which is generally 8 bits, and is not dependent on whether the architecture is 32-bit or 64-bit.
The "32-bit" or "64-bit" part of a system specification generally refers to two things: the size of is addresses (for pointers to memory) and the size of its registers (for on-CPU computation). This has no impact on actual data, whether stored on disk or sent over the network.
Amber
2010-10-12 05:40:33
A:
At the level of abstraction you are talking about, there should be no problem. 32 vs 64 will not affect network communication at the socket level.
Chris Thompson
2010-10-12 05:41:34
sure there will be no problem at the socket level. But wont there be problems in storing data. For instance if the data transfered is a 'long'(64-bit) value from a LP64 system to a 32-bit(ILP32) system. The number of bytes transferred will be 8 but at the receiving end 8 bytes will be stored when actually it should be 4
sandeep
2010-10-12 05:47:11
@sandeep: That's not how it works. 8 bytes is 8 bytes, no matter whether you're on a 32-bit system or a 64-bit system; bytes are 8 bits on both.
Amber
2010-10-12 05:51:19
@amber, you beat me to it. @Sandeep, when you're working at the tcp level, you only work in bytes, not in any sort of primitive data type. Even among 32-bit machines an int isn't always the same...think little endian vs big endian. That's actually an even bigger problem!
Chris Thompson
2010-10-12 05:54:00
A:
I think the question has been misunderstood by the previous two answerers. The OP's comments indicate that they are transferring a long from an LP64 system to an ILP32 system, presumably both x86.
On an LP64 x86 system, the long primitive type is 64 bits wide, least significant byte first. On an ILP32 x86 system, the same long primitive type is 32 bits wide, least significant byte first.
Problems will arise if you naively code with the long datatype and transfer numbers to and fro. You might be debugging on your x86_64 development PC and everything seems to work (with you memcpy()ing everything) and it breaks in mysterious ways on an i386 system because you're trying to squeeze 8 bytes into a 4-byte long.
This is why stdint.h was introduced in the C99 standard library. It allows you to write more portable code by specifying precise widths for your integers. If you want a 64-bit wide unsigned integer, use uint64_t. This type is invariant across ILP32 and LP64 x86 systems. Likewise, if you want a 32-bit wide signed integer, use int32_t. See this article on Wikipedia for much more information on the topic.
Sedate Alien
2010-10-12 06:13:54
I will clarify a little more:machine A(LP64 -stores long as 64 bit)------------>transfer data over TCP------>machine B(ILP32 -stores long as 32 bit)TCP is stream transfer so 8 bytes will be transferred over the network.Machine B will receive 8 bytes. But the value being expected was a 32 bit value.So according to you the problem will exist . And the way to resolve it is use datatypes like int64_t and uint32_t. Am I correct?.
sandeep
2010-10-12 06:37:21
@sandeep: I clarified the last paragraph in my answer. The type definitions in stdint.h were provided to solve this precise problem. You can choose exactly how wide your integer types will be and be sure of this across platforms.
Sedate Alien
2010-10-12 06:42:07