how does a receiver know when sendto() is done?

[drewdaman]

Hello again.

A little background info:
I have a client server architecture. most of the sending is done from teh server. initially i use tcp to communicate between the client and server to set up some variables (since tcp is reliable). then i use udp to transfer a file (udp because of the type of data i'm sending).. i receive the file on the client side in an infinite while loop:

while (true){
receive
etc.
}

my server also sends in a loop, but not an infinite one. i break the files into chunks the same as the buffer size.


-----------------
The problem:

this is not the greatest way to receive i guess.. i need to know when teh server is done sending.
--------------------------
Options that i considered:

one option is to send a datagram with a closing message (over udp). But this might not be so good because udp is unreliable and the packet might get lost and the client will just keep waiting to receive data. another option is to send an ack from the client. but again, we face the same problem and the server might just keep waiting.

another option i thought of would be to maintain a tcp connection throughout and send a closing message on that.. but i am not allowed to use two ports. this is a restriction that i can't change. i have to use only one port! at the moment , i do my tcp stuff, close the connection and then use the same port for my udp stuff.

would really appreciate any ideas on this and how to figure out if my server is done sending.

thanks,
drew

[ReorX]

Why are you using UDP instead of TCP? TCP does pretty much what you need without too much overhead.
With UDP, you might even have funny problems in larger networks when a datagram may overtake another datagram (because of different routes) - do you have sequence number in your datagrams, so that the file is correctly reassembled at the client?
If you want to stick to your UDP architecture, I would recommend that you transmit the number of chunks or the file size with TCP and additionally a timeout value. Afterwards transmit the rest with UDP. The client can tell whether he has received all datagrams by counting the size or the number of chunks or if the timeout times out between two packets, the client can throw awy everything and try to get a retransmission of everything.
But as I said, TCP can handle all this much better without overhead.

[Lee Peart]

Whether you use TCP or UDP you still need to define your own application level protocol.

TCP and UDP are network layer protocols and each has it's uses...

TCP guarantees that the the data will be received just once and in the correct order it was sent but you might not receive it all in one data packet or maybe more than one data message in a single packet.

UDP doesn't guarantee you will receive the data packet or that you will receive the packets in the order they were sent. You might receive duplicate packets too. What UDP does do though is deliver the packets as single complete data messages, as they were sent.


Whichever network layer protocol you decide to use, you need to add the logic to your Server and Client applications, and the messages they use to communicate, to be able to correctly send, receive and process those messages.

If you need further help with any specific aspects of defining your application layer protocol just ask. I'm sure lots of people have their own preferred methods but there isn't really any single best way, a lot depends on your precise requirements.

[drewdaman]

hi there,

thanks for replying. i'm sorry i took a while to do so, but its a long weekend up here in canada, so was away from work.

what this app is eventually supposed to do is transfer mp3 files much the same way that internet radio works. there might also be video later on. may also be other things like jpegs and stuff. thats why i chose udp. plus, thats the way the boss wants it! i don't really care if i lose a packet or two on the way... as long as a decent amount of the file can be played at the client.

i like the timeout idea. how would i go about implementing that? also, if you guys still think that tcp would be better for me, plz let me know!

thanks again!
drew

[Mathew Joy]

If you don’t mind loosing a couple or so data packets (and don’t mind the out-of-order ones ) then UDP is great. I think for movie and sound packets, you can afford to loose some packets. Mark those packets your client needs to respond. Once the client gets this packet it responds with a, say ack, packet. Now either the packet or the ack can get lost. So the best way to handle is to timeout the server’s recvfrom() which recvs the ack, and re-send the packet again. This should continue until the server gets the ack packets. On the clients side, for every duplicate packet you get, which you need to respond, send an ack without processing (since it is a duplicate packet). Next question is about timeout. Find an optimum value which should obviously be greater than the RTT.

Hope that helps

[drewdaman]

hey guys,

thanks for the suggestions. i like this timeout thing. but i dont' really know how to implement it. how do i timeout? is there a wait() function or somethign? i don't really know how to code it.

thanks again!

[Mathew Joy]

You can use setsockopt() with the SO_RCVTIMEO option to TO blocking sockets, or you can use non-blocking sockets with appropriate notifiers like select().