[twsocket] TWSocketServer: how to make it listening to several IP:Port ?
Hello all, Since the Addr property is a string, the component could easily handle any special format in that field to support multiple listening IP:Port (Interface to listen to and port to use on that interface). I think something like /192.168.1.1:80/0.0.0.0:81/. IPv4 or IPv6 could be used. The component can easily find out that there is a multiple IP:Port because of the / at the beginning. The port property would be used as default value when no prot is specified in the Addr for a given IP. As an example: Addr := /192.168.1.1/192.168.2.1/10.1.2.3:80/ and Port := 81 would make listening on port 81 for 192.168.1.1 and 192.168.2.1, and listening on port 80 for interface 10.1.2.3. The working would be this: The main TWSocketServer component listen on the first IP:Port specifyed and create secondary TWSocketServer instances to listen to the other IP:Port. The main instance keep track of the secondary instances. A new r/o property MultiListenList (and btw MultiListenListCount) would gives the list of all TWSocketServer, in the order specified in the Addr property. All TWSocketServer share the same list. Each get a new property MultiListenIndex which is their index in that list. All event handlers are common to all TWSocketServer instances. MultiListenIndex would be -1, MultiListenList would be nil and MultiListenCount would be 0 if TWSocketServer is used alone. If needed, but not sure it is, new methods could be added to handle all TWSocketServers at once: MultiListenListen, MultiListenClose and so on. This design would not break any existing code and would ease using the new multiple listen easy to implement in higher level components. What do you think ? -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to several IP:Port ?
Hello Francois, Of course it will be a cool design but I do not see any need for multiple listening except 0.0.0.0 and ::0 as I have seen none of the servers doing it. Regards, SZ On Fri, Nov 26, 2010 at 11:12 AM, Francois PIETTE francois.pie...@skynet.be wrote: Hello all, Since the Addr property is a string, the component could easily handle any special format in that field to support multiple listening IP:Port (Interface to listen to and port to use on that interface). I think something like /192.168.1.1:80/0.0.0.0:81/. IPv4 or IPv6 could be used. The component can easily find out that there is a multiple IP:Port because of the / at the beginning. The port property would be used as default value when no prot is specified in the Addr for a given IP. As an example: Addr := /192.168.1.1/192.168.2.1/10.1.2.3:80/ and Port := 81 would make listening on port 81 for 192.168.1.1 and 192.168.2.1, and listening on port 80 for interface 10.1.2.3. The working would be this: The main TWSocketServer component listen on the first IP:Port specifyed and create secondary TWSocketServer instances to listen to the other IP:Port. The main instance keep track of the secondary instances. A new r/o property MultiListenList (and btw MultiListenListCount) would gives the list of all TWSocketServer, in the order specified in the Addr property. All TWSocketServer share the same list. Each get a new property MultiListenIndex which is their index in that list. All event handlers are common to all TWSocketServer instances. MultiListenIndex would be -1, MultiListenList would be nil and MultiListenCount would be 0 if TWSocketServer is used alone. If needed, but not sure it is, new methods could be added to handle all TWSocketServers at once: MultiListenListen, MultiListenClose and so on. This design would not break any existing code and would ease using the new multiple listen easy to implement in higher level components. What do you think ? -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to several IP:Port ?
I do not see any need for multiple listening except 0.0.0.0 and ::0 as I have seen none of the servers doing it. No commercial server listens on 0.0.0.0 since commercial servers all have multiple IP addresses with multiple users and multiple applications, with the exception of IIS that hogs all addresses even if they are not used, unless you tell it otherwise. I have no problem with Francois's suggestion for a seemless user interface, but await Arno's comments since he has implemented various multilisten servers before and is aware of the internal issues. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to several IP:Port ?
On Fri, Nov 26, 2010 at 4:28 PM, Angus Robertson - Magenta Systems Ltd an...@magsys.co.uk wrote: I do not see any need for multiple listening except 0.0.0.0 and ::0 as I have seen none of the servers doing it. No commercial server listens on 0.0.0.0 since commercial servers all have multiple IP addresses with multiple users and multiple applications, with the exception of IIS that hogs all addresses even if they are not used, unless you tell it otherwise. In IIS 7.5, there is the option of selecting All Unassigned. We have the 0.0.0.0 IPv4 equivalent of it in ICS but that does not cover IPv6 ::0. What I said is if we can provide a mechanism to cover really all unassigned, the rest could be managed with multiple server components. However if you want to have your own server listen an IP on the same port, you must set it a higher boot priority group. Otherwise forcing IIS to allocate even only one IP is impossible. SZ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to several IP:Port ?
Otherwise forcing IIS to allocate even only one IP is impossible. It is quite possible, my public server uses IIS/7 and an ICS web application on different IPs. There are NETSH HTTP IPLISTEN commands that force IIS to listen only on specific IPs, or just change some registry settings. My applications have arrays of server components to support multiple IPs and ports, all using the same events, but all created in code. Building multiple listens into the component is really only beneficial for those that prefer to drop one component on a form. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to severalIP:Port ?
Francois PIETTE wrote: This design would not break any existing code and would ease using the new multiple listen easy to implement in higher level components. It won't break existing code, but remains a hack IMO. All event assignments and unassignments have to be kept in sync. Also I would not bind the construction/destruction of the additional instances to the Addr string property (grrr), instead let the user explicitly create additional server instances. That could be, for instance, a method like: TWSocketServer.AddServer( const AServerClass: TWSocketServerClass; const AAddr: String; APort: String; AListenBackLog: Integer): TWSocketServer; virtual; .. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening toseveralIP:Port ?
This design would not break any existing code and would ease using the new multiple listen easy to implement in higher level components. It won't break existing code, but remains a hack IMO. I don't agree with you. Please explain. All event assignments and unassignments have to be kept in sync. They will be easily with setter and getter. Also I would not bind the construction/destruction of the additional instances to the Addr string property (grrr), Why grrr ? Please explain. instead let the user explicitly create additional server instances. That could be, for instance, a method like: TWSocketServer.AddServer( const AServerClass: TWSocketServerClass; const AAddr: String; APort: String; AListenBackLog: Integer): TWSocketServer; virtual; Such a method could complement the design I suggested, updating the addr and other properties. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to
Hello! Hello all, Since the Addr property is a string, the component could easily handle any special format in that field to support multiple listening IP:Port (Interface to listen to and port to use on that interface). I think something like /192.168.1.1:80/0.0.0.0:81/. IPv4 or IPv6 could be used. The component can easily find out that there is a multiple IP:Port because of the / at the beginning. The port property would be used as default value when no prot is specified in the Addr for a given IP. As an example: Addr := /192.168.1.1/192.168.2.1/10.1.2.3:80/ and Port := 81 would make listening on port 81 for 192.168.1.1 and 192.168.2.1, and listening on port 80 for interface 10.1.2.3. Now let's assume that application listens on two ip:port pairs, each for different kind of communication. For example, 192.168.1.1:2048 and 192.168.1.1:27015. Also, let's assume that user can define on which ip:port one of servers should listen (another ip:port pair would be fixed). What happens if user enters /192.168.1.1:2048/192.168.1.1:27015/ (for example, because he/she heard/read somewhere that with new ICS this is possible, and the application is based on ICS)? There would be clear conflict between either: - one of server components that now owns both ports and another that attempts to bind to owned port *or* - the second component that correctly owns 27015 port and first component that attempts to bind subservers to both 2048 and 27015 ports (depends on component creation order). While that change doesn't directly break existing code, it might introduce difficult to understand bugs, as seen above. One workaround I see now is to filter the user input, but that adds new code to equation. Another, and what I think the most reasonable, is to create a new class derived from TWSocketServer that would accept such input and leave original TWSocketServer untouched. Just my 5€. -- Piotr Dałek enigmati...@interia.pl -- Chcesz wiÄcej zarabiaÄ? ZmieĆ pracÄ na lepszÄ ! http://linkint.pl/f2849 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer: how to make it listening to
Since the Addr property is a string, the component could easily handle any special format in that field to support multiple listening IP:Port (Interface to listen to and port to use on that interface). I think something like /192.168.1.1:80/0.0.0.0:81/. IPv4 or IPv6 could be used. The component can easily find out that there is a multiple IP:Port because of the / at the beginning. The port property would be used as default value when no prot is specified in the Addr for a given IP. As an example: Addr := /192.168.1.1/192.168.2.1/10.1.2.3:80/ and Port := 81 would make listening on port 81 for 192.168.1.1 and 192.168.2.1, and listening on port 80 for interface 10.1.2.3. Now let's assume that application listens on two ip:port pairs, each for different kind of communication. For example, 192.168.1.1:2048 and 192.168.1.1:27015. Also, let's assume that user can define on which ip:port one of servers should listen (another ip:port pair would be fixed). What happens if user enters /192.168.1.1:2048/192.168.1.1:27015/ (for example, because he/she heard/read somewhere that with new ICS this is possible, and the application is based on ICS)? There would be clear conflict between either: - one of server components that now owns both ports and another that attempts to bind to owned port *or* - the second component that correctly owns 27015 port and first component that attempts to bind subservers to both 2048 and 27015 ports (depends on component creation order). This is not different than usual. Any application asking for to listen on a IP:port has to be ready to be refused because the port is already in use. Having multiple IP:port created by a single component doesn't change anything here. The application would handle it exactly the same way. While that change doesn't directly break existing code, it might introduce difficult to understand bugs, as seen above. I don't agree with you. The design as I suggest make it totally equivalent to having multiple independant TWSocketServer component with common event handlers. One workaround I see now is to filter the user input, but that adds new code to equation. Another, and what I think the most reasonable, is to create a new class derived from TWSocketServer that would accept such input and leave original TWSocketServer untouched. The design I suggest make TWSocketServer still behave exactly as currently, just allowing a new syntax for addr property. If not used, then no change in code is required. But yes, maybe a new derived from TWSocketServer could be used, or better maybe a new intermediate class between TWSocketServer and TCustomWSocketServer. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
