Yep.
The bind is the same thing the listen did in your
example above. In order to listen you have to bind your socket handle to a
specific port.
I think what you are worried about is being able
to work with a known port. Most applications run the server on an already
known port, and all the clients use that port to listen for incoming data.
When you recieve data you can get the remote IP/port and that's what you would
use to send the data back too. On the client side you just set up a
recieve on that same socket. Or you can have the client set up a listening
socket and a sending socket, and the same for the server. The client sends
to the server's known listening port, and the first packet it sends tells the
server what client port it should send the data to (the client's listening
port).
And now you're getting around to just doing
tcp... The only reason why you would want to use udp is if you don't need
guaranteed packet delivery, or when such a guarantee would degrade the
application. For example, streaming video or audio, dropping a packet here
or there will just cause a very small bit of "static", but if the client were
using tcp it would actually hang until it had re-querried the server for that
packet and had received it before it would continue to play the stream.
And for a live conference this would be unacceptable. Another
characteristic typical of udp is a large amount of data going one way.
Usually apps that will send data back and forth will use tcp, but if there is a
small request and then a lot of data coming back as a response (and the delivery
guarantee isn't needed), then udp is usually used.
Think it through, you may be wanting tcp.
I'll admit, I've never needed to use it and my concept of re-using the listening
port to also send from may not work.
/dev
|
_______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
