Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.
Solved
c socket programming : file transfer problem
Posted on 2008-10-12
Hi,
In the attached server.c and client.c code snippets, if I don't use
bzero,
then,
at the client side, some extra/strange characters appear at the end
of client.txt.
I want to know why?
server.txt is as simple as this :
----file beginning---
abcd
---file end---
All I am trying to do here is to transfer server.txt, from server to client.txt
at the client.
In the attached server.c and client.c code snippets, if I don't use
bzero,
then,
at the client side, some extra/strange characters appear at the end
of client.txt.
I want to know why?
server.txt is as simple as this :
----file beginning---
abcd
---file end---
All I am trying to do here is to transfer server.txt, from server to client.txt
at the client.
server.c :
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#define PORT 2080
main()
{
int sock1,sock2, clength;
sock1 = socket(AF_INET,SOCK_STREAM,0);
struct sockaddr_in serv,cli;
serv.sin_family = AF_INET;
serv.sin_port = htons(PORT);
serv.sin_addr.s_addr = inet_addr("127.0.0.1");
bind(sock1,(struct sockaddr *)&serv, sizeof(serv));
listen(sock1,5);
clength = sizeof(cli);
int i=0;
char buf[50];
sock2 = accept(sock1,(struct sockaddr *)&cli,&clength);
printf("\n Client Connected\n");
FILE* fp = fopen("server.txt","r");
while(!feof(fp)){
//bzero(buf,sizeof(buf));
fread(buf,sizeof(char),50,fp);
write(sock2,buf,50);
}
write(sock2,"quit1234",50);
fclose(fp);
return 0;
}
client.c :
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#define PORT 2080
main()
{
int sock1;
sock1 = socket(AF_INET,SOCK_STREAM,0);
struct sockaddr_in serv;
serv.sin_port = htons(PORT);
printf("%x %x\n",PORT,htons(PORT));
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = inet_addr("127.0.0.1");
printf("client connecting\n");
connect(sock1, (struct sockaddr *)&serv,sizeof(serv));
char buf[50];
FILE* fp = fopen("client.txt","w");
while(1){
//bzero(buf,sizeof(buf));
read(sock1,buf,50);
if(strcmp(buf,"quit1234")==0)
{
break;
}
fprintf(fp,"%s",buf);
}
fclose(fp);
}
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
5-
5
10 Comments
You are using fprintf to output your buffer. It expects a null terminated string for it to determine where the end of the buffer is. bzero fills your buffer with null characters so that only characters in the buffer are the ones that you have sent and the remainder of null characters, which is why fprintf currently works for you with bzero there.
read returns a length of the buffer read. common practice is to null terminate the buffer after the read if you intend to use printf functions, or you can restrict the length of your fprintf outpu tto the specified buffer length.
read returns a length of the buffer read. common practice is to null terminate the buffer after the read if you intend to use printf functions, or you can restrict the length of your fprintf outpu tto the specified buffer length.
I am not clear about many things here.
Suppose the file to be transferred has 54 bytes.
(i) At the server side, while reading the file
in the first iteration :
I am reading 50 characters
in fread, so there is no place left for inserting '\0' in buf.
So, how does it matter, whether bzero has been used or not?
And the client is actually receiving those 50 bytes correctly.
(ii) In the next iteration, I read 4 bytes in buf.
What happens to the rest 46 bytes in buf[50]?
Does fread change them? Or do they have
previous values assigned to them? If they have
the previous values assigned to them, then
those characters should go to the client. Instead,
some strange binary data is being transmitted.
If fread changes them, then what does it
actually do with them?
Suppose the file to be transferred has 54 bytes.
(i) At the server side, while reading the file
in the first iteration :
I am reading 50 characters
in fread, so there is no place left for inserting '\0' in buf.
So, how does it matter, whether bzero has been used or not?
And the client is actually receiving those 50 bytes correctly.
(ii) In the next iteration, I read 4 bytes in buf.
What happens to the rest 46 bytes in buf[50]?
Does fread change them? Or do they have
previous values assigned to them? If they have
the previous values assigned to them, then
those characters should go to the client. Instead,
some strange binary data is being transmitted.
If fread changes them, then what does it
actually do with them?
You are creating a stack based variable for your buffer. It is never going to be empty as is the nature of stack variables and must be initialised properly.
You have two choices, either put a null character at the end of your buffer buffer, or limit the output to the length that you have read.
If you have a 50 character buffer, there is no guarantee what is next. buf is efffectively a pointer, and whilst you have 50 characters allocated on teh stack for it what is either side of those 50 characters is anyones guess. You could be lucky and find a zero byte is the next one, byut then again, you most likely will not be, but that depends on the architecture of the system you are running this program on.
fprintf thinks the only way to work out where the end of a %s is is when it finds a zero byte.
You can use the attached code bits to output what you want.
You have two choices, either put a null character at the end of your buffer buffer, or limit the output to the length that you have read.
If you have a 50 character buffer, there is no guarantee what is next. buf is efffectively a pointer, and whilst you have 50 characters allocated on teh stack for it what is either side of those 50 characters is anyones guess. You could be lucky and find a zero byte is the next one, byut then again, you most likely will not be, but that depends on the architecture of the system you are running this program on.
fprintf thinks the only way to work out where the end of a %s is is when it finds a zero byte.
You can use the attached code bits to output what you want.
int len;
len = read(sock1, buf, 50);
fprintf(fp, "%.*s", len, buf);
Sorry for late reply.
I have few more questions.
I will ask them one by one.
Firstly, what does bzero actually do?
Does it copy zeroes or '\0's in the
array? Are both of them same?
I have few more questions.
I will ask them one by one.
Firstly, what does bzero actually do?
Does it copy zeroes or '\0's in the
array? Are both of them same?
thanks.
secondly,
if server.txt has 330 characters,
then client.txt has 350 characters.
So, what's happening is client.c is reading 20
more characters in the last iterations since it couldn't
locate the end of string.
But why does it read only 20 more characters?
Why doesn't it go beyond those 20 characters?
Or am I getting plain lucky here?(in the sense that
the byte after the char array is 0)
secondly,
if server.txt has 330 characters,
then client.txt has 350 characters.
So, what's happening is client.c is reading 20
more characters in the last iterations since it couldn't
locate the end of string.
But why does it read only 20 more characters?
Why doesn't it go beyond those 20 characters?
Or am I getting plain lucky here?(in the sense that
the byte after the char array is 0)
No there are only 330 chars to read. However, your server program is writing out 50 byte chunks each time which is why you have the discrepancy.
So your client is reading correctly what is being sent. At the moment however, because both programs are working in blocks of 50 bytes you are hanging together. When you apply fixes to your server however you will potentially get problems again if your buffer is not zeroed because it is still using the fprintf without a length (unless you have implemented my earlier suggestions)
To fix the problem fread returns a length indicating how many characters where actually read. If you use this as the length parameter to your your write then you will get the the correct number of bytes.
So your client is reading correctly what is being sent. At the moment however, because both programs are working in blocks of 50 bytes you are hanging together. When you apply fixes to your server however you will potentially get problems again if your buffer is not zeroed because it is still using the fprintf without a length (unless you have implemented my earlier suggestions)
To fix the problem fread returns a length indicating how many characters where actually read. If you use this as the length parameter to your your write then you will get the the correct number of bytes.
int len = fread(buf,sizeof(char),50,fp);
write(sock2,buf,len);
}
char *quitStr = "quite1234";
write(sock2,quitStr,strlen(quitStr));
ok.
just one more.
suppose that 50 characters are read correctly in 'buf'
using
char buf[50];
fread(buf,sizeof(char),50,
then,
if I call
fprintf(fp,"%s",buf);
is it guaranteed that buf will be printed correctly?
Since, in 'buf' there is no '\0' anywhere, so will
fprintf stop at buf[49] or will go beyond buf[49]
searching for '\0'?
just one more.
suppose that 50 characters are read correctly in 'buf'
using
char buf[50];
fread(buf,sizeof(char),50,
then,
if I call
fprintf(fp,"%s",buf);
is it guaranteed that buf will be printed correctly?
Since, in 'buf' there is no '\0' anywhere, so will
fprintf stop at buf[49] or will go beyond buf[49]
searching for '\0'?
It will go beyond. As I have said before you need
int len;
char buf[50];
len = fread(buf,sizeof(char),50,
fprintf(otherfp, "%.*s", len, buf);
Notice the .* in the format string for fprintf and the additional len parameter.
That is saying print a maximum of 'len' characters, but be warned that if you have a null in your buffer then you also won't see all of the buffer that may have been read. That is why it is better to use the basic read/write methods on sockets or files where you expect non-alphanum characters in your character set.
your example above has fprintf outputing to the same socket stream that you are reading from. That can confuse the issue.
int len;
char buf[50];
len = fread(buf,sizeof(char),50,
fprintf(otherfp, "%.*s", len, buf);
Notice the .* in the format string for fprintf and the additional len parameter.
That is saying print a maximum of 'len' characters, but be warned that if you have a null in your buffer then you also won't see all of the buffer that may have been read. That is why it is better to use the basic read/write methods on sockets or files where you expect non-alphanum characters in your character set.
your example above has fprintf outputing to the same socket stream that you are reading from. That can confuse the issue.
Featured Post
Lunarpages' assortment of hosting products and solutions ensure a perfect fit for anyone looking to get their vision or products to market. Our award winning customer support and 30-day money back guarantee show the pride we take in being the industry's premier MSP.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
In this post we will learn different types of Android Layout and some basics of an Android App.
WARNING:
 If you follow the instructions here, you will wipe out your VTP and VLAN configurations.  Make sure you have backed up your switch!!!
I recently had some issues with a few low-end Cisco routers (RV325) and I opened a case with Cisco TA…
Internet Business Fax to Email Made Easy -
With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number.
You'll receive secure faxes in your email, f…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Suggested Courses
Course of the Month6 days, 16 hours left to enroll
704 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.