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
