tags:

views:

127

answers:

3

We have made simple client.c and server.c programme in an UNIX environment. We are using it transfer a simple text file by first opening it, then reading it and sending using open, read, and send system calls; on client side I am receiving it, and writing it by creating a file on server machine. The transfer is taking place quite smoothly but the file recieved at the client side is not exactly the same on the server side. In between the readable characters there are some unreadable characters. Can you please tell me what could be the possible reason for this? Though the most part of the file is same, only a small part in between has some discrepancies.

Code can be seen here.

Thanks!

server side loop:

do
{
    n=read(t,buf,100);
    write(1,buf,strlen(buf));
    send(connected, buf,strlen(buf), 0);    
} while(n!=0);

on client side

do
{
    bytes_recieved=recv(sock,recv_data,100,0);
    count=write(t,recv_data,strlen(recv_data));  
} while(bytes_recieved!=0);
A: 

MS Windows systems use carriage return-linefeed as a line ending, linux using just linefeed.

The "unreadable character" is Ctrl-M, the carriage return, character number 13.

tpdi
not unless their code says so, it isn't. stdio does CRLF/CR conversion sometimes, but the read/write system calls don't.
Alnitak
p.s. he also said this was under UNIX
Alnitak
You can't know that. According to the OP the environment is UNIX. They didn't say a Windows client to a UNIX server. It could just as easily be buffering issues or other corruption. We can't know until they post something.
Jason Coco
When I answered this, the OP had posted no code. The only thing I had to go on was the OP's statement that "in between the readable charachter there are some unreadable charachter." I was merely trying to eliminate the obvious.
tpdi
I think that's generally better done in comments, that way there are no misleading answers for confused newbies :)
Jason Coco
@tpdi - the OP said from the outset that a) he was using system level calls and b) that it was UNIX. That almost makes your "obvious" CRLF guess impossible.
Alnitak
A: 

You should check your send()s to see if they succeed. You may find that at some point the write buffer (that is, the socket's output buffer) is full and the send fails. This is normal behavior. Send returns the number of bytes sent. If you are not sending multibyte characters, this would probably manifest as missing data rather than corruted data. If you lose one byte of a two byte character, it could result in corruption.

Sam Hoice
+1  A: 

In the first instance, don't use strlen(). There's absolutely no guarantee that there'll be a NUL byte anywhere in the file stream, and in fact with a text file there never should be.

Each time around the loop you should output the actual number of bytes that were received, not how many strlen() thinks might be in the buffer:

do
{
    bytes_received = recv(sock, recv_data, 100, 0);
    if (bytes_received < 0) {
        perror("read");
        break;
    } else if (bytes_received == 0) {
        break;
    } else {
        count = write(t, recv_data, bytes_received);
        // in theory - add error check here too!
    }
} while (count > 0);
Alnitak
i have removed strlen and replaced with the actuall recv return but still there is same problem of some(few) unreadable charachter.my second question can we use the same mechanism to send binary file or any other file like songs and videos,or do we need to change the programme to send these kind of file.Thanks!
mawia
you need to change the other half of the code not to use strlen() either - I only showed one half. Once it's correct it'll transport any file regardless of type.
Alnitak