Re: [msvc] UDP 1 last question

[max]

HI     I think what you are worried about is being able to work with a known port.    Yes, I defiantly want the server to listen on a known port 4010.  As for the client I don't care - Windows can allocate it (as it should do?) as long as they can use full duplex communication.    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.     Ok this is my understatding of a server.  It creates a socket, binds it to a know port and then wait to recieve data.  Once it has recieved data the sAddr should be filled with the address and that can then be used to send data back to the client with sendto?     NOTE: I'm not sure the above is correct.  I'm sure I had an application watching the port No and doing that the sendto make the PORT No jump from a listening port no the the same as the client???       Server   CreateSocket PORT = 4010 Bind(PORT, IP)   SOCKADDR sAddr;   while(1) { recievedata( &sAddr ); }     ... Another thread or something   while(1) { senddata( sAddr ); }       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).     The client just creates a socket and Connects to a known IP - Port No and sends data.  One you call connect I think Window assigns a port no to the socket so you can just call recv???      Client   CreateSocket Connect( PORT, IP )   while(1) { Senddata }     ...... Another thread or something   while(1) { recvdata() }         And now you're getting around to just doing tcp...      Nope - I definatly don't want TCP.  This is a streaming audio and so TCP is out.  The only reason I want to set things up with a connect is to try and make sure I only have two people talking at a time - without anyone else sending unwanted data to that port.....      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.     Nope defiantly UDP       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.     I think this is pretty much what I'm confused by...  What I've written is How I think this work and not necessarily how they do work.  Any corrections welcome.   Regards Max

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.3.0 - Release Date: Mon 21/02/2005

_______________________________________________
msvc mailing list
msvc@beginthread.com
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for 
subscription changes, and list archive.