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.
(Check out this http://www.velocityreviews.com/forums/t665299-off-topic-strange-behaviou
r-adding-printf-change-the-prograexecution.html)
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.
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.
(Check out this http://www.velocityreviews.com/forums/t665299-off-topic-strange-behaviou
r-adding-printf-change-the-prograexecution.html)
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