2

What is the best Component for a Client-Server (TCP) application with thousands of clients involved whereas all connections must stay alive ?
So far I have used Indy with one TIdTCPServer in the server application and one TIdTCPClient in all of the client applications. I want both the clients and the server to send data at any time and any size.
Is this a good approach?

sausagequeen
  • 81
  • 7
MohsenB
  • 1,669
  • 18
  • 29
  • 1
    Something [`related`](http://stackoverflow.com/q/15924616/960757). – TLama May 10 '13 at 09:42
  • 1
    See also [Scalable Delphi TCP server implementation](http://stackoverflow.com/questions/7150093/scalable-delphi-tcp-server-implementation) – mjn May 10 '13 at 10:15
  • 1
    See [this blog entry about DataSnap concurrent access](http://robertocschneiders.wordpress.com/2012/11/22/datasnap-analysis-based-on-speed-stability-tests/) - sounds indeed like if Indy does not scale well. With 1000th clients, take a look at IOCP/Event driven servers, like http://www.realthinclient.com/ or our Open Source http://mormot.net – Arnaud Bouchez May 10 '13 at 11:53
  • @ArnaudBouchez do you have any references/pointers that RTC uses IOCP? – mjn May 10 '13 at 13:15
  • @mjn This is the premise everywhere in their website. Quote: "Other than most other internet components, RTC connection components are non-blocking and event-driven. This means that, even when not using a multithreaded mode, your users will not be blocked (“Application Not Responding”) during communication between your client and the server. For each state change in the connection, there is an event that will be triggered." Perhaps they are not using IOCP WinAPI, but at least, they are using event-driven server design, which is the only one to scale with thousands clients. – Arnaud Bouchez May 10 '13 at 14:31

1 Answers1

3

It might work, but it might also end up with a lot of problems depending on what kind data, load, security and so on. I ended up using a web server (Tomcat + Comet). The work is already done : socket stability, framework, security, load sharing across several instance etc... A thousands of client is not that easy to handle... And then you can focus on your application, and only on it.

Greg M.
  • 229
  • 1
  • 9
  • 1
    +1, Java (Netty, Servlets) ranks high up in http://www.techempower.com/blog/2013/04/05/frameworks-round-2/ – mjn May 10 '13 at 10:19
  • 1
    -1 AFAIK Indy does not implement IOCP so will create one thread per client connection. So it won't be able to handle thousands clients, without triggering an Out Of Memory error. IOCP/EventDriven server is needed here, and Indy does not feature this kind of architecture. @mjn Java server are out of scope, and out of mind in the context of this question, I'm afraid. Just compare the memory consumption, behind the "hello world" JSON request. :) – Arnaud Bouchez May 10 '13 at 12:45
  • 1
    @ArnaudBouchez : Client side will only consume 1 thread ... because it's the client ;). On the server Side, i won't use indy nor Delphi to build a server (why would i rebuild the wheel ?). – Greg M. May 10 '13 at 12:52
  • 1
    @GregM. I was speaking of the SERVER side, of course. Please read the main question again. It is about *server* side ability of handling thousands of connections using an Indy server. This is not possible yet, due to the design of Indy. Handling thousands of clients can be very easy, without reinventing the wheel, but relying on proven IOCP/EventDriven servers - which exists in Delphi flavor. No need to switch to Java, which will add a big overhead to the server side process, for sure. – Arnaud Bouchez May 10 '13 at 14:33
  • @ArnaudBouchez : I misread your answer as it was a comment to my answer and i was talking of something else than a delphi server :). Java is not THE solution, only a solution. – Greg M. May 10 '13 at 17:25