Re: udp client and server
You should not be using UDP for something like this. It is (by design) an unreliable protocol and if you go through all the work of trying to make it reliable by sending ACKs back and forth, then you've just made a more complicated and non-standard form of TCP. Use TCP instead. Thousands of programmer man-hours have already gone into it.
Re: udp client and server
I know that TCP use ack messages for reliable transmitting but my aim is different, I will design a discovery protocol and I need to do it with udp datagrams, and ACK message will contain encrypted text for authentication, I mean not like exactly TCP's ack messages...
thanks for reply...
Re: udp client and server
Since there is no "connection" between a UDP server and a client (and not a well-defined idea as to what it means to be a "server" or "client" with respect to UDP), then data exchange gets complicated. Because there is no "connection" information associated with UDP, recvfrom() and sendto() must be used as they have the extra sockaddr parameter to indicate where the packet came from/goes to.
Your brief description above indicates that you probably plan on sending out a broadcast and see who answers, right? In essence, the machine that sends the broadcast is the client in this scenario and each potential receiver of the broadcast must act as a server of sorts "listening" (I put that in scare quotes because you don't really listen() with UDP) for a UDP packet from the broadcaster. Is this an accurate assessment of your goal?
Re: udp client and server
yea it won't be broadcast exactly but the idea is smilar. Server will send a message and if the client recieves that message - will reply server's message (ack),, as you said.. so how can I do such a program ? there are any examples ?
Re: udp client and server
OK, if you're not sending a broadcast, then you must have a sockaddr struct for each machine you are using sendto() to "send to." Why can't you recvfrom() using the same socket and sockaddr?