mismatch size

hi all,
 Right now my program is very close to work. It sends files from client to server. However, there is a mismatch in portion of file while sending 1 file. Somehow, it happens at the last  portion. tks a lot.
server.c
client.c
BeginToLearnAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

phoffricCommented:
Your server code:
	n = read( sock, pch, size_to_read);
	sizedata = n;
	printf("n is %d and size_to_read is %d\n", n, size_to_read);
	if(n < size_to_read)
	{	
		error("Error in receiving data buffer");
	}

Open in new window

If n < size_to_read, that is not necessarily an error. On an error, -1 is returned.
0
BeginToLearnAuthor Commented:
but in this context , receving wrong sizeof of data is considered error. right?
0
phoffricCommented:
Try this.

client: put a break on the send
server: put a break on the read

when both reach the break, do next on client to send
then in server do next on the read

do you still get a mismatch?

The man page indicates when you get an error. But you are right to be concerned about application error.

The application error is that if the entire file is not transferred (or, I've seen this in your earlier code), if the new file is larger than the original, then you have an error.

If you want to treat a chunk of the file as a message, then you have to loop until you get the entire message. I wasn't a proponent of doing it this way, but you chose to define message 3 for each chunk.
0
JavaScript Best Practices

Save hours in development time and avoid common mistakes by learning the best practices to use for JavaScript.

BeginToLearnAuthor Commented:
I ran debugger and set the code break at line sendOneFile and receiveOneFile( both at line 98. that's why sometime u see space because i want of of them has same line number ) . I see they are matching. but the last portion is wrong size
0
phoffricCommented:
I was talking about the send in sendMessage and the read in receiveMessage.
0
BeginToLearnAuthor Commented:
sorry email delay. I am running it now.
0
BeginToLearnAuthor Commented:
Receiving match with receiving !!!

In my folder program, i have client.c, server.c, client, server. It send client ( size= 83432) file and create new file "client 83432"( size . 77824) and the last portion is 1512
0
phoffricCommented:
Sorry, I don't follow the problem you are having. Could you explain a little more clearly what the discrepancy you have between the client and server and the lins of code that you are breaking on to see the problem.
0
phoffricCommented:
And also let me know whether you modified your program to address the error handling point made in the first post.
0
BeginToLearnAuthor Commented:
For testing purpose, i change change the error handling point in first post like this:
  if(n != size_to_read)
      {      
            printf("mismastch in receiving data buffer\n");
            //error("Error in receiving data buffer");
      }

because I want to identify send or receive part to pay attention at.
Then i get those terminal message:

Current working dir: /home/ubuntu/program
message1-> total number of files is 4
message2 -> filename is :/home/ubuntu/program/client 25536
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 2048
in message3, len is 960
size is 25536
message2 -> filename is :/home/ubuntu/program/server.c 5785
in message3, len is 2048
in message3, len is 2048
ubuntu@ubuntu:~/program$


ubuntu@ubuntu:~/program$ ./server
n is 1 and size_to_read is 1
message1-> total number of files is 5
n is 33 and size_to_read is 33
message2 -> filename is :/home/ubuntu/program/client 25536
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 1984 and size_to_read is 2048
mismastch in receiving data buffer
in message3, len is 1984
writing : result is 1984
n is 56 and size_to_read is 1164209765
mismastch in receiving data buffer
in message3, len is 56
writing : result is 56
n is 960 and size_to_read is 960
in message3, len is 960
writing : result is 960
n is 34 and size_to_read is 34
in message3, len is 34
writing : result is 34
n is 2048 and size_to_read is 2048
*** stack smashing detected ***: ./server terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x50)[0x2e0970]
/lib/libc.so.6(+0xe591a)[0x2e091a]
./server[0x8048f8b]
[0x3b647473]
======= Memory map: ========
00110000-001ef000 r-xp 00000000 08:01 1311830    /usr/lib/libstdc++.so.6.0.14
001ef000-001f3000 r--p 000de000 08:01 1311830    /usr/lib/libstdc++.so.6.0.14
001f3000-001f4000 rw-p 000e2000 08:01 1311830    /usr/lib/libstdc++.so.6.0.14
001f4000-001fb000 rw-p 00000000 00:00 0
001fb000-00352000 r-xp 00000000 08:01 2360647    /lib/libc-2.12.1.so
00352000-00354000 r--p 00157000 08:01 2360647    /lib/libc-2.12.1.so
00354000-00355000 rw-p 00159000 08:01 2360647    /lib/libc-2.12.1.so
00355000-00358000 rw-p 00000000 00:00 0
0094b000-00967000 r-xp 00000000 08:01 2360642    /lib/ld-2.12.1.so
00967000-00968000 r--p 0001b000 08:01 2360642    /lib/ld-2.12.1.so
00968000-00969000 rw-p 0001c000 08:01 2360642    /lib/ld-2.12.1.so
0097b000-0099f000 r-xp 00000000 08:01 2360651    /lib/libm-2.12.1.so
0099f000-009a0000 r--p 00023000 08:01 2360651    /lib/libm-2.12.1.so
009a0000-009a1000 rw-p 00024000 08:01 2360651    /lib/libm-2.12.1.so
00b25000-00b3f000 r-xp 00000000 08:01 2354767    /lib/libgcc_s.so.1
00b3f000-00b40000 r--p 00019000 08:01 2354767    /lib/libgcc_s.so.1
00b40000-00b41000 rw-p 0001a000 08:01 2354767    /lib/libgcc_s.so.1
00e12000-00e13000 r-xp 00000000 00:00 0          [vdso]
08048000-0804b000 r-xp 00000000 08:01 1570089    /home/ubuntu/program/server
0804b000-0804c000 r--p 00002000 08:01 1570089    /home/ubuntu/program/server
0804c000-0804d000 rw-p 00003000 08:01 1570089    /home/ubuntu/program/server
09320000-09341000 rw-p 00000000 00:00 0          [heap]
b77a4000-b77a7000 rw-p 00000000 00:00 0
b77b3000-b77b6000 rw-p 00000000 00:00 0
bfef8000-bff19000 rw-p 00000000 00:00 0          [stack]
Aborted
ubuntu@ubuntu:~/program$ g++ -o server server.c
ubuntu@ubuntu:~/program$ ./server
n is 1 and size_to_read is 1
message1-> total number of files is 4
n is 33 and size_to_read is 33
message2 -> filename is :/home/ubuntu/program/client 25536
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 2048 and size_to_read is 2048
in message3, len is 2048
writing : result is 2048
n is 1984 and size_to_read is 2048
mismastch in receiving data buffer
in message3, len is 1984
writing : result is 1984
n is 56 and size_to_read is 1164209765
mismastch in receiving data buffer
in message3, len is 56
writing : result is 56
n is 960 and size_to_read is 960
in message3, len is 960
writing : result is 960
n is 34 and size_to_read is 34
in message3, len is 34
writing : result is 34
n is 2048 and size_to_read is 2048
*** stack smashing detected ***: ./server terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x50)[0x334970]
/lib/libc.so.6(+0xe591a)[0x33491a]
./server[0x8048f8b]
[0x3b647473]
======= Memory map: ========
0024e000-0024f000 r-xp 00000000 00:00 0          [vdso]
0024f000-003a6000 r-xp 00000000 08:01 2360647    /lib/libc-2.12.1.so
003a6000-003a8000 r--p 00157000 08:01 2360647    /lib/libc-2.12.1.so
003a8000-003a9000 rw-p 00159000 08:01 2360647    /lib/libc-2.12.1.so
003a9000-003ac000 rw-p 00000000 00:00 0
005ee000-00612000 r-xp 00000000 08:01 2360651    /lib/libm-2.12.1.so
00612000-00613000 r--p 00023000 08:01 2360651    /lib/libm-2.12.1.so
00613000-00614000 rw-p 00024000 08:01 2360651    /lib/libm-2.12.1.so
008d5000-009b4000 r-xp 00000000 08:01 1311830    /usr/lib/libstdc++.so.6.0.14
009b4000-009b8000 r--p 000de000 08:01 1311830    /usr/lib/libstdc++.so.6.0.14
009b8000-009b9000 rw-p 000e2000 08:01 1311830    /usr/lib/libstdc++.so.6.0.14
009b9000-009c0000 rw-p 00000000 00:00 0
00d74000-00d90000 r-xp 00000000 08:01 2360642    /lib/ld-2.12.1.so
00d90000-00d91000 r--p 0001b000 08:01 2360642    /lib/ld-2.12.1.so
00d91000-00d92000 rw-p 0001c000 08:01 2360642    /lib/ld-2.12.1.so
00dda000-00df4000 r-xp 00000000 08:01 2354767    /lib/libgcc_s.so.1
00df4000-00df5000 r--p 00019000 08:01 2354767    /lib/libgcc_s.so.1
00df5000-00df6000 rw-p 0001a000 08:01 2354767    /lib/libgcc_s.so.1
08048000-0804b000 r-xp 00000000 08:01 1570089    /home/ubuntu/program/server
0804b000-0804c000 r--p 00002000 08:01 1570089    /home/ubuntu/program/server
0804c000-0804d000 rw-p 00003000 08:01 1570089    /home/ubuntu/program/server
08a3d000-08a5e000 rw-p 00000000 00:00 0          [heap]
b789d000-b78a0000 rw-p 00000000 00:00 0
b78ac000-b78af000 rw-p 00000000 00:00 0
bfd53000-bfd74000 rw-p 00000000 00:00 0          [stack]
Aborted
ubuntu@ubuntu:~/program$


Clueless !!!

 
0
phoffricCommented:
Originally, you had
   if(n < size_to_read)

and now you have
   if(n != size_to_read)

Originally, there was a mismatch between n and size_to_read where n was less than size_to_read; and this resulted in an early termination.

In your revised if statement, if n is still less than size_to_read, then since n != size_to_read, then you also report an error. But the man page says that an error occurs if n = -1.

Did you use the breakpoint idea and still get a mismatch?

Do you get a core file left over?
0
BeginToLearnAuthor Commented:
From previous ddd run, i see match.

oh after i change
   if(n != size_to_read)

I ran them so i didn't have core file. So I need to run ddd again.But i go to work now and comeback midnight. So please post idea if u see something wrong. So i can think of solution while working. tks a lot for ur time and understanding.
0
phoffricCommented:
how about
 if ( n == -1 )
    error
0
BeginToLearnAuthor Commented:
Just arrived work place.does it work on ur sytem wit n ==-1 I cant run now
0
phoffricCommented:
For the first run, it works. For other runs where I leave the new files with spaces in them, it begins to run funny and eventually crashes as the names become weirder. But that is another problem unrelated to the mismatch.

If I hear you right, the program works fine in the debugger when you control the timing in the way I described earlier - no mismatch, right.

Only when you let it roll on its own, you get a mismatch. But, a mismatch is not an error. So, you should not call perror and exit, when you know you have success (just as perror reported).
0
BeginToLearnAuthor Commented:
When I run debug,i run 2 ways
  .1nextt in client n 1 next in server
 . Let client run until it finishes sending file 1, then just next next on server
both peosuce match
0
phoffricCommented:
I was thinking you had a timing difference from what I see here. That is why I asked you to run observantly in the debugger, where you say that the program works as expected.

Going with the assumption that you are sending out more than you can chew in one gulp, then you can either:

(1) rewrite the receiveMessage() so that it actually gets a message. That is, you have to stay in this function looping until you get the entire message (for example, typically 2048 bytes, in your code).

or,

(2) do not make the individual chunks a message. Notice that message 2 provides the filename and filesize. This filesize is all the server needs to read in the body of the file. In this case the client and servers still send out message 1 and 2. But now what follows message 2 is the first chunk of the file and then chunk 2 (but no message id or length). You can create a new function to do this on both sides.

About the remainder (term used in your first post days ago). From message 2 you know the entire filesize. And for each chunk that you receive, you know the current remainder. You just adjust the amount of data you want to be the minimum of 2048 and the remainder. And stop when the remainder is 0.

To make sure that the client and server are synchronized, here is an application test that you could add if you wish. After the client completes the transfer of a file, let it send out an a Message 4 that represents the EOF. After the server has closed the file (i.e., when remainder is 0), then it reads the next message which must be a message 4, or else there is an application error.

Although you should change the test to ( n == -1 ), which will solve the early termination problem, it will not help you with the lack of synchronization between client and server due to the timing issue.

But at least we now understand that the mismatch problem is to be expected and handled correctly. If you have problems doing that tomorrow, then you can ask how. But give it a try.
0
BeginToLearnAuthor Commented:
Let me try once I get home at midnight.i believe this is tge last issue we have
0
BeginToLearnAuthor Commented:
I am just curious about the tweasted version that worj. Doesnt it have aame problem?
0
BeginToLearnAuthor Commented:
The first thing i try when i just got home is n == -1. It could works for the first file then stack smashing dectected... like i mentioned before.  Then it read two portion of second file and stop without any error message (client side)
0
BeginToLearnAuthor Commented:
I am thinking of those ideas you mentioned above. I think sychronization between server and client can be take care of network layer. While debugging, if i just click "next" , "next"... on server, it just wait until it receive message from client before moving to "next" .
0
sarabandeCommented:
begintolearn, the receiving side not necessarily gets the buffer with one read. normally the tcpip puts your message into a bigger packet with additional sender and receiver information. such a packet is not so much larger than your 2k buffer (on many systems). so, it is not unlikely that a 2k buffer you send was splitted into two packets. at the receiver side those packets were unpacked but it doesn't actually wait for a missing part of a buffer but if your call to recv happens between two packets it would return the part already received and you would get the rest by a second call.

that's why when you expect a buffer of a known size you always have to put your recv within a while loop that reads as long as the number of bytes count up to the expected total:

   
int nread = 0;
   while (nread < (int)size_to_read)
   {
        int result = recv(sock, &buffer[nread], size_to_read - nread);
        if (result <= 0)
        {
             error();
             break;
        }
        nread += result;
   }

Open in new window


look at the code and you see that we start reading at &buffer[0] with the full expected size. then we add the actual number of bytes we received to the nread. if the nread now is the size_to_read, the loop breaks and we are done. if not, it would read again but now at &buffer[nread] what is behind the data read before. and the buffer size (of the rest) we also adjust by size_to_read - nread.

do you get the point?

Sara
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
phoffricCommented:
>> The first thing i try when i just got home is n == -1. It could works for the first file then stack smashing dectected...

This is no surprise. That is why in http:#35224171 I suggested two different design remedies for this. What happened is that when you got less than the amount expected in your 2K chunk of data, then you were now out of sync with the client. When the server reads a message, if out of sync, then the values in the message are no longer valid, and so some kind of error is to be expected. In your case it happens to be stack smashing. Had you used the message_id properly in a test, this would have been more apparent to you. You can ask a question on how to use the message_id properly (but please try to think about it). Why bother designing and sending a message_id, if the server is not going to even use it.

The mismatch problem resulting in early termination of your program is solved, you didn't realize that your read could get less than your expected amount of bytes. (All of us had tried to explain this here and in previous questions, but for a project of this complexity, it is easy to be overwhelmed with all the information.)

Now that you have code (which strikes a resemblance to your one of your file reading designs prior to using messages, doesn't it), I think the question of early termination has been resolved. You now have a new issue.

And, I believe there is an issue in your client; but if I'm right that will arise after more testing. Hopefully, the discussion here resolves your early termination issue; and you can thank Sara for the code, as I was going to let you write your own for this project.
0
BeginToLearnAuthor Commented:
srrry I just wake up and now go to work from 10 to 7 pm. I will read all comments carefully during break. There is no doubt about my appreciation regarding to  all advises, especially to Sara.
0
sarabandeCommented:
yes, phoffric was right. i shouldn't have given code. but we already had that issue and suddenly it was out of discussion but still made problems ...

i also see the problem with the too many cooks ... so i try to take me back sometimes but it is not easy if something runs obviously into wrong direction ...

Sara

0
sarabandeCommented:
some remark to the cooks: in one of the recent threads Kent (kdo) has said that he wouldn't send the size before data. indeed it is right that you can receive data without knowing the exact size before. but that requires additional efforts at the receiver side cause any read you do might be the last one and reading more data than being sent would cause your program to hang if you don't make sure there is something to read before calling recv. it is a different design and i don't say it is less good but you should be aware that when knowing the size to receive you have control of the process and more easily can find out if something goes wrong. for example the above while loop can only be made when you know the expected size. if not it even would be difficult to find out when a ingoing file needs to be closed and a second one begins.

Sara
0
phoffricCommented:
We had made the read point quite a number of times here and in previous questions. I think the problem is that instead of restricting the project questions to one question per question, we allow many issues to be raised. This is so well intentioned but leads to the some of the salient points not sinking in.

When I saw oo08 request that a previous question be closed once it was answered, I believe that helped that thread. Maybe both the experts and the author should strive to to take oo08's approach to upholding the EE policy of one question per question to keep each point clearer, and to make the PAQ search results more meaningful.

@Begin,
Also, to the point about making the PAQ search results more meaningful, if you could make your subject titles have more keywords, that would be useful. For example:
     Socket mismatch size between client and server
0
phoffricCommented:
>> Kent (kdo) has said that he wouldn't send the size before data
In this case, I agree with Kdo as the first thing a server needs to know is the format of the message type. Also, I'm sure Kdo meant that the server actually do something with the Mesage ID, and that something would detect errors. That the author did not do anything with the Message ID is, as I noted earlier, a glaring design issue. As I noted, why bother sending any entity if you are not going to use it. If the author wishes to discuss further the pros/cons of having a message header or not, and if a messge header, then the benefits of ordering certain items, then I'd be happy to discuss this further with you in a separate question. But that is up to the author whether this matter should be pursued.

I think learning should be done in small steps, and for homework projects, I don't strive for the best possible design. I'd rather see the students make their own decisions, learn how to implement them; see the issues that arise from the implementation; modify the implementation trying again for a better design. And I don't mean for that to happen in one assignment project. It takes us many falls to be able to walk upright.
0
BeginToLearnAuthor Commented:
I just read comments without pay attention aout technical  in my phone,i can say someting as I looking back to the begiining day:
  .i created spagetti code
  .kdo advised main structure
  .proffric advised all functions reorganization
   .sara advised messagetype to send an reeive

In addition more detail n specific details add  as along the way all I can see my code get improve a lot.all individyal  lline makes whole program work.sometimes very desperate,sometimes high hope,annd exciting.

so I very appriciated all help
0
Kent OlsenDBACommented:

>>I think learning should be done in small steps, and for homework projects, I don't strive for the best possible design. I'd rather see the students make their own decisions, learn how to implement them; see the issues that arise from the implementation; modify the implementation trying again for a better design. And I don't mean for that to happen in one assignment project. It takes us many falls to be able to walk upright.

I agree completely.

The thing that I keep going back to is simplify!  When fully 1/2 of a function can be discarded it's pretty clear that the programmer doesn't understand what is really happening and is throwing code at the problem trying to get lucky.

Notes:  
1.  The timing issues mostly go away if the handshake is full duplex (every message from the client gets a response, even if it's just "OK").  It actually implements quite easily, but it's probably beyond the scope of this exercise.

2.  If you're sending a message with no data (such as an ACK (ok)) no message length is needed.

3.  Having the server trust that it'll get a 4-byte length value from the client is equivalent to trusting that the server will get a 4-byte function (message) code.

4.  For completeness, the server does need to be stateful.  But again, that's probably beyond the scope of this exercise.


Kent
0
phoffricCommented:
>> The thing that I keep going back to is simplify!
I agree completely. You really helped the author make the code more readable with your suggestions.

>> The timing issues mostly go away if the handshake is full duplex
The trade-off in using an OK ACK per message is a performance penalty.

>> If you're sending a message with no data (such as an ACK (ok)) no message length is needed
Yes, and the Message ID would be used to understand the format of the message. In this case the Message ID could be the ACK with no further size or data (provided that we go with your idea that the Message ID is the first element in a message rather than the size).

>> For completeness, the server does need to be stateful.  But again, that's probably beyond the scope of this exercise.
I agree. In fact, before the author implemented the Message ID, I modified one of his code posts with maybe 3-4 corrections; and it worked on multiple runs (with only the folder issue remaining). This was before 10am on 22-Mar ( "from your OP, you were only a few lines of code away from getting this to work. " see http://rdsrc.us/tVr9sR ). Now, there appear to be client issues (which I don't recall seeing on 22-Mar in my tweaked code). At that time I fully expected that the author would have a working program by COB 22-Mar. Not to say that all the ups and downs isn't a great learning experience - it is. But if the deadlines pass, then there is a trade-off between high quality code and passing the course.
0
phoffricCommented:
>> For completeness, the server does need to be stateful.
Hmm, just to make sure we're on the same page.. At any given time the server is in a particular state.

Initially, it is in the GET TOTAL FILE MESSAGE state.

Then the server transitions to the GET FILENAME AND FILESIZE MESSAGE state.

Then the server transitions to the GET TRUNK STATE

Then it loops in last two states.

There could be an explicit END OF TRANFER STATE (but this is implicit from the value resulting from the first state).
0
Kent OlsenDBACommented:
>> Hmm, just to make sure we're on the same page.. At any given time the server is in a particular state.

Only in the loosest sense.  The state occurs because of what the server expects to do, not what the client requested the server to do.

There are no sanity checks or even attempts to use the function code sent in each message header.  Send any of the messages in the wrong order and havoc occurs.

The first receive() is executed in a call from receiveTotalFiles (to receiveMessage) and reads the total number of files to process.  The message type (1) is never checked.  Nor is it checked when the file name / data are sent.


Kent
0
phoffricCommented:
Ok, good. We're on the same page. :)
0
BeginToLearnAuthor Commented:
I am home now and start reading all technical comments.
0
phoffricCommented:
>> The timing issues mostly go away if the handshake is full duplex
Due to routing/timing, a read might get more than one send if the server's input buffer were larger than the send buffer; or the read might get less than one send even if there is handshake. A single 2K buffer send can result in less than 2K being received due to routing/timing/network-congestion issues.

In any case, even if this problem mostly goes away, unless it completely goes away, you have to assume that the problem exists and deal with it as if it never goes away.
0
BeginToLearnAuthor Commented:
I am reworking the receiveMessage based on Sara suggestion now. The main idea was " that's why when you expect a buffer of a known size you always have to put your recv within a while loop that reads as long as the number of bytes count up to the expected total"
0
BeginToLearnAuthor Commented:
it works !!!!!!!!!! ^_^
0
phoffricCommented:
Run it with folders including the client server .exe files say about 6 times and see if it still works. Do not delete the new files created from run to run.

By suggestion, I guess you are referring to the provided code that you plugged in, right?
0
BeginToLearnAuthor Commented:
I use provided code.
 After running 5 times, i has segmentation fault in server. i didn't delete new files created from run to run. So i can see one of files such as " server.c 5957 11914 11914 23828 47656" . Did u see same problem?
0
phoffricCommented:
I also got an error when doing this scenario. But with debug, before you finally get that hard error, you will see other forms of corruption.
0
BeginToLearnAuthor Commented:
Let me close this question and run debugger in several hours later. tks.
0
Kent OlsenDBACommented:
Hi Begin,

You don't need to open another question every time a thread gets long.  All of your questions are related to how to make your application work.  

Closed questions go into the Expert's Exchange PAQ (Previously Asked Question) library.  There's nothing at all wrong with having the entire development process contained within a single thread.


Kent
0
BeginToLearnAuthor Commented:
back to action. Running debug now.
0
phoffricCommented:
When is your deadline for this and getting the folders handled correctly on the server? To meet your deadline, is it more important to deal with folders on the server or to get the files transferred correctly when you repeat the operation multiple times without deleting the new files?

If you set up a complex tree with a wide variety of small and large text and binary files, do they all transfer correctly the first time (i.e., file content is the same)? If so, then at least for many cases, you have a program that works for most of the source tree. To meet the deadline, you could submit with a Known Issues Report that includes the one case where there is a problem; and that you will fix it in phase 2 of your project.
0
BeginToLearnAuthor Commented:
I submitted it last night with explanation and the code that can display folder hierarchy and how to create a folder  in order to get partial credit.This week is spring break.
I gonna research how to do project 2 which is based on project 1 . Due date is May 8. haiz.
0
phoffricCommented:
Just curious. Did you have to submit something for your other 24-March deadline?
0
BeginToLearnAuthor Commented:
This one was supposed to submit on 24. at that time it didn't work so i didn't submit at all.
0
phoffricCommented:
Did you lose credit for turning it in late? In programs at work, we have to sometimes make compromises between schedule and quality. Recall that I said in http://rdsrc.us/tVr9sR , you were just a few tweaks away from making your program work. Then you decided to redesigned the client/server protocol data transfer which caused you a 5-1/2 day delay.

Would you have been allowed to submit a working program (without folders, I know) and then re-submit with a better modularization resulting in an easier to read program this week. The fact that you redesigned the protocol without even making use of the Message ID was a mistake IMO.

Many laugh at Microsoft for their lousy Windows 1.0, 3.0, ME, Vista; yet they made over a trillion $$ in sales. And they finally came up with XP and then 7.
0
phoffricCommented:
Since you are working what appears to be long hours and difficult projects (all very commendable), then for future complex projects, you may wish to consider the trade-off between hiring a tutor that can help you get through the tough issues quickly vs. getting little sleep resulting in additional stress.

BTW, Kdo http://www.experts-exchange.com/M_993614.html has a HIRE ME button, and so do I http://www.experts-exchange.com/M_400954.html (I don't see one for sarabande). A tutor in person may even be the best solution.
0
BeginToLearnAuthor Commented:
let me email to your account to ask about it. tks.
0
Kent OlsenDBACommented:
Hi Begin,

You don't need a private tutor.  Don't waste your money.  I, for one, don't charge students.

You do need some consistent direction and advise.  Unfortunately, you've been caught in a push-pull and what we could probably have knocked out in 2 days has drug on this long due to things beyond your control.  A skilled C programmer could have knocked out most of your application between morning coffee and lunch.  For it to have taken this long and left you without a better understanding is shameful.

It's clear that you're pretty new to C, but you seem eager to learn and certainly seem determined.  Add some aptitude and that's a darned good formula for success.


When you're ready to start the next project, just post it here.  If you'll follow my lead I'll get you home with a far better understanding of the project and the solution than you've gotten with this assignment.

But don't waste you money on a tutor.
Kent
0
phoffricCommented:
In light of what Kdo stated, when you start your new project, then I will refrain from joining in for your best interest. From what I have seen, Kdo gives very nice explanations. I just hope others will follow this same line and let Kdo give you solid guidance without "too many excellent chefs" trying to make a Chinese/Italian cuisine in one pot.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming Languages-Other

From novice to tech pro — start learning today.