Dundas Ultimate TCP/IP - Anyone Use It?
-
I already sent this to dundas tech, but I don't know if I'm gonna get an answer before Monday, so I'm asking it here too, on the off chance that someone else here uses the package. ================================ Let's say I have a client app and a server app. I want the two apps to exchange traffic on a specific range of ports. If the server is listening on a port (we'll use 8000 for this example), I want it to do one of two things: A) Use the listening port (8000) to send/receive all traffic with the client that connected. **OR (and more preferrably)** B) Tell the client to use a specific port to connect to (for instance, I want to use ports in the range from 8001 through 8010). I need this capability so that people with firewalls/routers can open specific ports with which to use my programs. Is this possible with Ultimate TCP, and if so, do any of the samples illustrate one (or both) of the two methods? ============================== It seems to me that method (A) would be the least desirable, since it would essentially defeat the benefits of threading done within the CUT_WServer class (being able to handle connections on several ports at once). Only 11 ports will be needed at any given time (one to listen and 10 to actually exchange data), and the traffic will be a single burst of data (anticipating 8k max) followed by an immediate disconnect. Anyone with some experience in this area wish to comment?
-
I have used other Dundas products with generally good results. However there are some good MFC based freeware components here that work perfectly just for this. Ed
-
I have used other Dundas products with generally good results. However there are some good MFC based freeware components here that work perfectly just for this. Ed
-
Tell me about one "standard" service that works that way. All servives I know of, listen on one port, and does all of the communication on the same port. What you say makes impossible to put a server behind a firewall. If I put a, lets say, smtp server behind a firewall, I'll make a rule something like this "Allow all ipaddresses to connect to my smtp server, from any port to port 25". If the server would change port when talking to the client, the client would not be able to connect to the smtp server, be cause the firewall would block that. - Anders Money talks, but all mine ever says is "Goodbye!"
Typically (and this is only based on what I've seen happen), when a socket accepts a connection request, it selects a port at random and tells the connecting client to connect to that port in order to exchange data. As far as I know, there is no check (and I don't think it can be) to make sure the port is accessible through a firewall. In fact, it will even try to allow any port value from 1 to 65535 (notice that this includes the range of reserved ports from 1 to 1024). So, let's say you have a listening socket on port 8000. A connection request comes in and your software says "Okay, fine, connect on this 63221 so I can keep listening for connections." The port value was randomly selected (and the term "random" is used quite loosely, I might add). But what happens if that port isn't open on your firewall/router? The client will/should/might get a cannot connect error. What I want is a way to specify the port (or even better, a range of ports from) which the listening socket will select AFTER the connection is accepted. If a port in the range is busy, I want the listening socket to try the next one, and so on (with an appropriate timeout value of course).
-
I already sent this to dundas tech, but I don't know if I'm gonna get an answer before Monday, so I'm asking it here too, on the off chance that someone else here uses the package. ================================ Let's say I have a client app and a server app. I want the two apps to exchange traffic on a specific range of ports. If the server is listening on a port (we'll use 8000 for this example), I want it to do one of two things: A) Use the listening port (8000) to send/receive all traffic with the client that connected. **OR (and more preferrably)** B) Tell the client to use a specific port to connect to (for instance, I want to use ports in the range from 8001 through 8010). I need this capability so that people with firewalls/routers can open specific ports with which to use my programs. Is this possible with Ultimate TCP, and if so, do any of the samples illustrate one (or both) of the two methods? ============================== It seems to me that method (A) would be the least desirable, since it would essentially defeat the benefits of threading done within the CUT_WServer class (being able to handle connections on several ports at once). Only 11 ports will be needed at any given time (one to listen and 10 to actually exchange data), and the traffic will be a single burst of data (anticipating 8k max) followed by an immediate disconnect. Anyone with some experience in this area wish to comment?
Hi John, I'm sure Ghazi or another member of the TCP/IP team will give you a deeper response than this, but here are some thoughts: What you are describing is functionally similar to the FTP system, you should check out the FTP client and server examples that are included with the library for all the nitty gritty details. Basically the client and server connect() functions in Dundas TCP/IP allow you to optionally specify a port to use. In the case of servers you of course need to specify a port to listen on, and for clients you can specify the port to use locally (as in call out from port 2567 on this machine, and connect to port 80 at www.microsoft.com). In the case of FTP, the client contacts the server and establishes a "control" connection. That connection handles directory navigation, file operations etc. If you want to transfer a file (or a directory listing), the server tells the client "connect to port x on this machine to get your data" The niggling little details of TCP/IP communications (like that you have to honor a 30 second cooling off period before reusing the same (client ip, client port, server ip, server port) combination can become a real headache, which is why the samples and examples that come with Dundas TCP/IP are a major part of the benefit. I'd highly recommend that you try to match your overall objective against one of the provided samples (file transfer/synchronization, streaming, etc.) and then customize from there. HTH, David
-
Well, I already have the Dundas library so I figured i'd make use of it. It would be a great waste to have a $700 library taking up hard drive space and not use it.
Some other points: MFC shouldn't be used for server applications, Microsoft *actively* discourages that. The biggest problems revolve around MFC's use of idle time to do cleanup, and with server applications it's easy to have no idle time. Other issues such as MFC's window management can be very problematic in server use as well. Many people have the misconception that Dundas TCP/IP is an MFC centric product, which it isn't. Dundas TCP/IP is basically vanilla C++ with a few Microsoft centric tweaks in it. Many, many firms have ported Dundas TCP/IP to Solaris and Linux for use in those environments. David
-
Typically (and this is only based on what I've seen happen), when a socket accepts a connection request, it selects a port at random and tells the connecting client to connect to that port in order to exchange data. As far as I know, there is no check (and I don't think it can be) to make sure the port is accessible through a firewall. In fact, it will even try to allow any port value from 1 to 65535 (notice that this includes the range of reserved ports from 1 to 1024). So, let's say you have a listening socket on port 8000. A connection request comes in and your software says "Okay, fine, connect on this 63221 so I can keep listening for connections." The port value was randomly selected (and the term "random" is used quite loosely, I might add). But what happens if that port isn't open on your firewall/router? The client will/should/might get a cannot connect error. What I want is a way to specify the port (or even better, a range of ports from) which the listening socket will select AFTER the connection is accepted. If a port in the range is busy, I want the listening socket to try the next one, and so on (with an appropriate timeout value of course).
Hmmm, I have never seen that happend. I have spendt a great deal of time watching network traffic through a network sniffer, and all the services I have seen (except ftp that also uses port 20) they keep talking on the same port. If you connect to a POP3 server, it keeps talking with you on port 110. I have a lot of firewall configurations, and they would all fail if the server were listening on other ports, but they have all worked. Like the SMTP server we have at work. The only connections allowed through our firewall is on port 25, and ONLY port 25, but it works great :) I'm writing some serverbased stuff right now, and it also both listen for new connections, and talk to existing connections on the same port, and it works great for multible clients. I'm using IO Completion Ports for the server stuff, and it really scales well. :) - Anders Money talks, but all mine ever says is "Goodbye!"
-
Hmmm, I have never seen that happend. I have spendt a great deal of time watching network traffic through a network sniffer, and all the services I have seen (except ftp that also uses port 20) they keep talking on the same port. If you connect to a POP3 server, it keeps talking with you on port 110. I have a lot of firewall configurations, and they would all fail if the server were listening on other ports, but they have all worked. Like the SMTP server we have at work. The only connections allowed through our firewall is on port 25, and ONLY port 25, but it works great :) I'm writing some serverbased stuff right now, and it also both listen for new connections, and talk to existing connections on the same port, and it works great for multible clients. I'm using IO Completion Ports for the server stuff, and it really scales well. :) - Anders Money talks, but all mine ever says is "Goodbye!"
-
Typically (and this is only based on what I've seen happen), when a socket accepts a connection request, it selects a port at random and tells the connecting client to connect to that port in order to exchange data. As far as I know, there is no check (and I don't think it can be) to make sure the port is accessible through a firewall. In fact, it will even try to allow any port value from 1 to 65535 (notice that this includes the range of reserved ports from 1 to 1024). So, let's say you have a listening socket on port 8000. A connection request comes in and your software says "Okay, fine, connect on this 63221 so I can keep listening for connections." The port value was randomly selected (and the term "random" is used quite loosely, I might add). But what happens if that port isn't open on your firewall/router? The client will/should/might get a cannot connect error. What I want is a way to specify the port (or even better, a range of ports from) which the listening socket will select AFTER the connection is accepted. If a port in the range is busy, I want the listening socket to try the next one, and so on (with an appropriate timeout value of course).
Hello John and all, The best way to look at this issue is to understand how a socket is identified uniquely for the duration of it's usage. A socket is identified by four parameters. -local IP address -The local port number - The remote IP address - The remote port number. So even if the remote IP address, remote Port number and local IP address are the same, the socket will be unique in that the client will have a different local port number. A firewall will try to disable any attempt to connect to any port number that is not allowed by the administrator. So to allow your client application to work behind firewall , then the client should be allowed to connect to the specified server port number (for out going connections) For example, in order for a person behind firewall to use HTTP, the administrator usually will be allowing out-going connection on port 80. if the server is behind a firewall (usually not true). The server port number (in your example 8000) must be opened for incoming connection attempts.
So, let's say you have a listening socket on port 8000.
A connection request comes in and your software says "Okay, fine, connect on this 63221 so I can keep listening for connections."
The port value was randomly selected (and the term "random" is used quite loosely, I might add).
But what happens if that port isn't open on your firewall/router?
The client will/should/might get a cannot connect error.The example you describe above is not feasible for the reason you mentioned above. Since you have already made the connection and that you don't have to worry about the other incoming connection as they will be handled uniquely. However, if you wanted to add this functionality for security purposes. Such as having the login authentication to be handled on one connection and then ask the client to connect back on different port (to hide the port number from the man in the middle). The problem with this approach is that it will not be as secure, since we assumed it will have limited number of ports which makes it easy for trial and errors attempts. P.S. I hope this posting and the email I sent to your email answer your question Kindest Regards Ghazi H. Wadi Dundas TCP/IP Team
-
Hello John and all, The best way to look at this issue is to understand how a socket is identified uniquely for the duration of it's usage. A socket is identified by four parameters. -local IP address -The local port number - The remote IP address - The remote port number. So even if the remote IP address, remote Port number and local IP address are the same, the socket will be unique in that the client will have a different local port number. A firewall will try to disable any attempt to connect to any port number that is not allowed by the administrator. So to allow your client application to work behind firewall , then the client should be allowed to connect to the specified server port number (for out going connections) For example, in order for a person behind firewall to use HTTP, the administrator usually will be allowing out-going connection on port 80. if the server is behind a firewall (usually not true). The server port number (in your example 8000) must be opened for incoming connection attempts.
So, let's say you have a listening socket on port 8000.
A connection request comes in and your software says "Okay, fine, connect on this 63221 so I can keep listening for connections."
The port value was randomly selected (and the term "random" is used quite loosely, I might add).
But what happens if that port isn't open on your firewall/router?
The client will/should/might get a cannot connect error.The example you describe above is not feasible for the reason you mentioned above. Since you have already made the connection and that you don't have to worry about the other incoming connection as they will be handled uniquely. However, if you wanted to add this functionality for security purposes. Such as having the login authentication to be handled on one connection and then ask the client to connect back on different port (to hide the port number from the man in the middle). The problem with this approach is that it will not be as secure, since we assumed it will have limited number of ports which makes it easy for trial and errors attempts. P.S. I hope this posting and the email I sent to your email answer your question Kindest Regards Ghazi H. Wadi Dundas TCP/IP Team
Reformating of the above answer
Hello John and all, The best way to look at this issue is to understand how a socket is identified uniquely for the duration of it's usage. A socket is identified by four parameters. -local IP address -The local port number - The remote IP address - The remote port number. So even if the remote IP address, remote Port number and local IP address are the same, the socket will be unique in that the client will have a different local port number. A firewall will try to disable any attempt to connect to any port number that is not allowed by the administrator. So to allow your client application to work behind firewall , then the client should be allowed to connect to the specified server port number (for out going connections) For example, in order for a person behind firewall to use HTTP, the administrator usually will be allowing out-going connection on port 80. if the server is behind a firewall (usually not true). The server port number (in your example 8000) must be opened for incoming connection attempts. So, let's say you have a listening socket on port 8000.
A connection request comes in and your software says "Okay, fine,
connect on this 63221 so I can keep listening for connections."
The port value was randomly selected (and the term "random" is used
quite loosely, I might add).
But what happens if that port isn't open on your firewall/router?
The client will/should/might get a cannot connect error.The example you describe above is not feasible for the reason you mentioned above. Since you have already made the connection and that you don't have to worry about the other incoming connection as they will be handled uniquely. However, if you wanted to add this functionality for security purposes. Such as having the login authentication to be handled on one connection and then ask the client to connect back on different port (to hide the port number from the man in the middle). The problem with this approach is that it will not be as secure, since we assumed it will have limited number of ports which makes it easy for trial and errors attempts. P.S. I hope this posting and the email I sent to your email answer your question Kindest Regards Ghazi H. Wadi Dundas TCP/IP Team
