In my option a real ICS multi-listening server should handle all
client objects in one list. These client objects should be aware of
what listening socket accepted them.
That is a good idea.
This is not possible to achive
with current TWSocketServer design.
I wouldn't be so sure.
In the meanwhile I think I got the idea. A new very small class
"TWServerSocket" that is instantiated and registered by the
TWSocketServer for each new listening socket. "TWServerSocket.Listen"
calls WSAASyncSelect with TWSocketServer's window handle.
Small change, not a small new class but a TWSocketServer and currently
I override WMASyncSelect and Accept, works like a charm. The
MultiListenSockets are a TCollection descendant so accessible in OI
as well. The only limit is that they (the additional listening sockets)
must run in the same thread context as their owner TWSocketServer.
If that wasn't the case an assertion is raised.
The idea of a small class is a good idea altough it defenitely force al
events to be shared between all listening sockets. That's not a problem imo
but you raised the issue previously.
Means you have to
Add new listeners in the same thread context and you may not attach
the main instance to another thread context when there are
MultiListenSockets in the collection, what do you think?
Adding new listeners from another thread is not a problem if a custom
message is posted so that the code (the message handler) creating the new
listener is executed in the TWSocketServer thread whatever the originating
thread is.
--
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
