Programming

I understand all sockets programming until it comes to this level:
int read (int fd, char* buffer, size_t size); /* if i am right */
int write(int fd, char* buffer, size_t size);

My question is that: in my case I need to pass a structure between server and client, how to do that ??? (in other way: how to write binary data)

At one level could just you take the address of the structure, cast it to (char *) and you have the second parameter. And the third parameter can be obtained via sizeof.

But this whole approach is very wrong. You are assuming identical architectures for both systems. To explain how to do this right would take a book. Several have been written. Buy one and read it. Search this forum for book suggestions.

In case you really knows the structure passed is portable across systems, some people may choose RPC instead of socket, which has provisions for passing arbitrary structures. It is also well-known that RPC is not secure though.

Thank you both for your replies,

But Perderabo, what do you mean by identical architectures for both systems???

In my case the software I'm developing will be deployed under two operating systems (server side on windows, client side on tru64 UNIX). Currently I'm testing both sides on unix, and your method seems to work, however does that mean it won't when I convert the exact same equivalent server source code to windows ?????

We don't need to introduce other OS's to illustrate the problem. It will almost certainly fail when used between a sparc running solaris and an intel running solaris!

Now understand that you can get lucky and find two different systems that can successfully run your code. I don't have a prediction for the two systems you mention.

Here is an example of a program that fails because it assumes a particular structure for an integer. And no networking is involved, simply an abuse of read()/write() much like you plan to do.

ok .. Thanks Perderabo for your reply .. I get what you mean now

So Is there any other alternatives ??? like send(), recv() ???
(I never understood what they do, I just know they do much like read()/write() .. except read()/write() are 1000 times easier)

Underlying any socket communication is the read/write suite of functions (actually I think the vector routines are the most raw without going down to character by character level) however its a translation that you are looking for. A single 8 bit character, in essence, is the only information that will, bitwise, translate across a socket and be reliable on both ends.

I.E. if you send a character, with binary value 01100001 via write it will wind up on the receive end as 01100001 as expected. However, integers (on many systems) are 16 bits, or 2 bytes, or 2 characters. Some systems will represent them MSB, some LSB (or big/little endian). Therefore an integer with "in memory" value [00000001][10000000] on one machine may read [10000000][00000001] on another. Therefore sending the two characters (as an integer) 00000001 followed by 10000000 will wind up, potentially, having different integer values on each end.

Now this problem becomes more complicated in that some systems represent integers as 16 bits, some as 32 bits, some as 8 bits (if you go back long enough). Then you throw in things like byte alignment and other issues and you can get very confusing results.

For example, the structure:

Code:

struct
{
     int a;
     char b;
     int c;
}

On a machine with 32 bit (4 byte) integers (and normal 8 bit (1 byte) characters) could be 72 bits (or 9 bytes) on a machine whos naturally aligned on character boundaries (I doubt there are many). However many machines align on 4 byte boundaries, meaning that the character needs to take up a full 32 bits to insure that the next integer 'c' is correctly aligned, making most machines create a 12 byte structure.

Therefore even sizeof is not reliable.

Now, on to the solution. Basically, what generally happens is that at some level a precompiler generally takes a description of the structures that you want to communicate (such as RPCGEN for the RPC/XDR suite) and generates a set of routines that can traverse the structure on a given machine and convert it into a string of bytes that is in a "intermediate" agreed upon format. Then sends it across the socket (with write) and receives it on the other end and traverses this agreed upon format to reconstruct a similar structure on the other end. These routines are typically not too complicated, but need to be standardized and written for every machine that will be communiated to translate (bi-directionally) to and from that machine's native format.

There is also built-in macros/functions that can convert some primary types to a standard (called network) format. For integers and shorts (or more accurately 32 and 16 bit numbers) there is the htonl and ntohl and htons and ntohs routines, which stand for (host to network long) (network to host long) (host to network short) and (network to host short). These typically should be passed the (uint32_t and uint16_t) types respectivelly to guarentee that 32 and 16 bit integers are used for your machine, because as mentioned before some machines use different "native" sizes for int, long, and short.

So there's a primer...hope it helped. I've currently been smack in the middle of writing a huge communication API for my company which had to address a lot of these concerns. I ended up using the RPC XDR suite to do the translation and built a much better, in my opinion, communication suite are pre-existing structure translation rather than use the RPC paradigmn directly since it really isn't designed to do bi-directional client/server asynchronous type communication like we needed.

Well, if I can clarify anything else...I'd be glad to if I have the time.

Brian Gregg
Computer Sciences Corp.