"wenming hu" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> thank u very much!
I don't recommend it. Unlike TCP, UDP is designed to break up its
packets and it takes a fairly sophisticated server app to put the
packets in the right order and to ask for missing packets it did not
receive. You can build it with some fairly good success with VB6
Winsock control, or perhaps something in Java, PHP, or .NET, but once
the packet size hits a certain limit, the packets start breaking apart
and chaos starts to happen. Also, as your corporate net teams tweak
the routers your app could suddenly stop working, as my UDP service
stopped working about 10 years ago, forcing me to switch to smaller
UDP messages and then ultimately forcing me to switch the app to
complete TCP.
A better design is to make a TCP server that acts like passive FTP --
one authentication port and a series of callback ports in a designated
range like 21000-21100. The client calls the server on port, say,
19000, says hello and authenticates properly, and then the server
says, "call me back on your designated port of 21001". The client then
calls back on that port and the server interacts with it. So what good
is UDP at that point? UDP is great, at that point, to act as a
"heartbeat", constantly checking the server with very short messages
to determine if it can respond (more sophisticated than just a simple
ping) to requests or is overloaded or has a hung TCP connection, which
then tells the client to drop the connection and try to re-establish
it, and, failing that, tell the client to post an error message.
Hope this helps.
|
Similar Threads
Linear Mode
