Saturday, June 8, 2013

Related Topic: The most important lesson learned in Phase 3

The client/server programs began to malfunction after I added CRC into the frame. After 
transmission, the file on server side is not of the same size as the one on client side. Initially 
I thought it is caused by the CRC calculation function and the related functions. I modified 
some of them, but it still doesn't work. Then I started to look at the server side, and added 
some code into the server program. Somehow the programs worked again. The only thing 
I've added is a printf function. This is a problem that has confused me for a long time, i.e. 
would the printf function affect the execution of the code besides printing out its parameters 
on the standard output. The answer is yes if you are doing multiple-threaded or network 
programming, because the printf function you added would cause a delay to the execution 
of other part of the program. 
That's why after adding the CRC part, the program malfunctions -  the calculation of the
CRC delays the sending of the frames from sender to receiver. Thus for some callings of
the function recv, it does not receive the entire frame (or receive nothing). After I adding
some code into the server side, the additional code caused some delays on the server side,
making the server slow down its reading from the socket. 

How to know if the server (or the receiving end) always read the entire frame? 
Add these code after the recv function. 
//Receive frame from client
ssize_t numBytesRcvd = recv(clntSocket, &fmRecv, FSIZE, 0);
if(numBytesRcvd<0)
perror("recv() failed");
if(numBytesRcvd!=FSIZE)
perror("Receivd unexpected number of bytes");
(FSIZE is the size of a frame) 
Note our code does not guarantee that for each calling of function recv, the receiver would
 receive an entire frame (the use of function select() introduced in Phase 4 will solve 
this problem), but it will tell you when the receiver does not. 

No comments:

Post a Comment