Programming

It does not work that way. You can not write an EOF to a socket any more that you can write EOF to a file. EOF is not a character. You need to close() or shutdown() the socket. Only then will the other side see an EOF condition.

I have a question. If doing a file transfer, shouldn't there be acks sent back to the source, so that the source can send the next datablock?

I think that a sequence like this would work:

file dest:send ack. file src: wait for ack.
file src: get ack. send data. file dest: wait for data
file dest: get data. send ack. ..... so on.

if at any point, if the file src doesn't get ack, it can resend the data, and we could use normal read and write on the sockets.

FWIW - some OSes have an actual EOF character. DOS uses ascii 26 for EOF for "text" files, for example.

I think that's where the idea of an EOF character came from.

Yes I made a mistake, It doesn't send EOF at all, sorry for my bad english!
But as a matter of fact if you build a client and a server only with those two function(send_file and get file) it works, try to do so.
I took the example from "The C programming language" book. Actually the example was copying between 2 files or from stdin to a file(I can't remember now...), but since a socket is threated like a low level I/O descriptor(that with function similar to system call not FILE *) if you replace the descriptor with the socket it should work the same. I tried and it worked so, why? What's wrong with my reasoning?
Any comment?
Thanx everybody.
Ciao

The fact is that when you run the 2 function alone, the send_file function finishes while the get_file function waits. When send_file finishes immediatly halt the program so closing sockets! That's why get_file function finishes as well, because it sees the socket's closure .
Sorry for the banal question!
And thanx for all answers.
Ciao
Matteo