mea@sparta.com (Mike Anderson) (02/10/91)
Archive-name: internet/programming/servesend/1991-01-17 Archive: titan.rice.edu:/sun-source/servesend.c [128.42.1.30] Original-posting-by: mea@sparta.com (Mike Anderson) Original-subject: Re: Pipes, sockets and coms processes Reposted-by: emv@ox.com (Edward Vielmetti) With stream sockets, there is no way for the receiver to know how long the message is without the programmer's intervention. I.e., what you typically do is to set up a fixed size header format that includes a length field. You read from the socket until you have a full message and then you use the length field to tell you how many more bytes you have to read before you have the complete message. A word of caution: the select() call will indicate that there is data to be read when the very first byte shows up. Stream sockets do not preserve record boundaries so you have to use an approach like the one outlined above and loop on the read until enough data arrives to determine the actual message length. Here is an example: [[Ed's Note: Pretty long - I dumped it in the archives. -bdg]] FTP: Hostname : titan.rice.edu (128.42.1.30) Directory: sun-source Filename : servesend.c Filesize : 9942 bytes Archive Server Address: archive-server@rice.edu Archive Server Command: send sun-source servesend.c The compilation is a simple cc (i.e., ignore the VXWORKS stuff 'cause that's for a real-time single board computer that we sell) and it would look like this: cc -o benchmark benchmark.c cc -o recv recv.c Start the benchmark program with: benchmark 3000 1000 1 (port 3000, 1000 1024-byte msgs, 1 client) and recv "<benchmark host name>" 3000 (same port as benchmark) They should connect and go to town :-). The number of messages specified is DIVIDED evenly among the number of clients (e.g., if there were 2 clients they would each get 500 msgs). Just run recv as many times as you have clients specified. Good luck, Mike Anderson mea@sparta.com