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 ?
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
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