With UDP what you see is what you get -- you can launch a packet towards its destination, but that's as far as it goes. The network will do its best to deliver, but it offers no guarantee of success, and cannot tell whether it succeeded or not.

If you want to send more than one packet's worth of data, you'll have to wrap each fragment of data in something to tell the other end which part of the data each packet contains -- so the receiver can tell if any fragment goes missing. If you want to know the data has arrived, you'll need to get the receiver to send packet(s) back, telling you how it is for them (consider what happens if those packets do not arrive). From that information, you might be able to deduce that some packets need to be resent. There's a bit of a special case to deal with when you've sent all the data. Alternatively, if you are confident that UDP packets will be delivered, you could get the client to repeat the entire request when it finds a packet has gone astray. (Don't forget to deal with the case of packets being delayed in the network and turning up at the receiver some time later; in particular in the middle of a different request/response cycle.)

Or you could use TCP. The obvious model here is DNS. Most DNS requests are dealt with using UDP. The client gets to repeat the request if it doesn't hear a response in some reasonable time, and there's a mechanism to detect multiple responses rolling up (the server does not attempt to care -- a request arrives, a response is sent, job done). If the response is too big for a single UDP packet (of minimum size), the server says so -- it's up to the client to repeat the request, but using TCP.

I recommend Stevens.