NetCom7 is an extremely optimized code on TCP/IP sockets. Forget using one thread per connection. With this suite, you can have as many concurrent connections to your server as you like. Threads are used per request and not per connection, and are maintained in a very fast thread pool class.

The NetCom version 7.2 package is now multi-platform! You can compile your apps under all platforms in FireMonkey as well as VCL!

The implementation begins with TncTCPServer and TncTCPClient which implements the basic socket communications. You can use TncTCPClient and TncTCPServer if all you want is to implement standard (but very fast) socket comms.

On top of the TCP/IP sockets, a lightweight protocol is implemented to be able to pack and unpack buffers (simple TCP/IP is streaming and has no notion of a well-defined buffer). The set of components implementing this functionality is TncServerSource and TncClientSource. Both of these components implement an ExecCommand (aCmd, aData) which triggers an OnHandleCommand event on the other side (a client can ExecCommand to a server, or a server can ExecCommand to any client).

Simple server scenario:

• You put a TncServerSource on your form.
  If you want you can change the port it is listening to via the Port property.
• You implement an OnHandleCommand event handler and, depending on aCmd parameter (integer), you respond to the result of
  the command via setting the Result of the OnHandleCommand to
  anything you like (TBytes).
  • If an exception is raised while in HandleCommand, it is trapped, packed, transferred across to the calling peer, and raised at the peer’s issued ExecCommand.
  • This way exceptions can be handled as if they were raised locally.
• You set the Active property to true. Your server is ready.

Simple client scenario:

• You put a TncClientSource on your form. You can set Host and Port to whatever value desired.
• You set Active property to true. Your client is now connected to the server.
• You call ExecCommand (on your TncClientSource), with any command number and data that you like. This will send your command and data over to the server, call its OnHandleCommand, pack the response, and return it as a result to your ExecCommand.
• ExecCommand is blocking (if aRequiresResult parameter is set to true), but only for the current command issued.
  The TncClientSource’s OnHandleCommand still executes, so, while waiting for a command to return, your client socket might be processing requests from your server (a server can also ExecCommand to a client).
• If you have forgotten to set Active to true and call ExecCommand, the TncClientSource will first try to connect, so you can omit setting a value for this property. It will also try to connect if it knows it has been disconnected (and the Reconnect property is set to true).

Performance

A simple timing test with the NetCom VS Indy demo gives the following results:

• Testing Indy… Time taken: 32468 msec
• Testing NetCom… Time taken: 25109 msec

Starting with the base unit, ncSockets.pas, you will see that the implementation does not suffer from slack code, it is rather immediate. The inline calling convention has been used wherever deemed appropriate. The very core functions have been tested and optimized by monitoring the performance via the timing of large loops and assembly inspection to squeeze out every last bit of performance.

The biggest difference though in speed gain is due to the architecture. Unlike most typical sockets: This set of sockets does neither spawn nor use a thread per connection.

This means you can have as many live connections as you like and you will see NO difference in performance! A thread pool just waits for any requests; if a thread was to be created per request or per connection, the speed would suffer a lot, as creating a thread is quite heavy time-wise. If the number of requests per second cannot be handled by the thread pool, the thread pool grows up to a maximum defined size, and if it still cannot cope, the client just waits until the server gets a ready thread to process its request.

The disconnects are picked up immediately, and if a line is so bad that the disconnect cannot be picked up, it tackles this by a keep alive packet by which it gets to know the actual status. There is a Reconnect property and a KeepAlive property. When a client gets disconnected, for whatever reason, it tries to reconnect transparently and without affecting the main application’s performance. This way you do not have to worry about keeping your clients connected.

Compression and encryption are also standard with these components with no extra libraries required. Ofcourse you can use your own compression or encryption if you prefer, but it is rather handy to have just a property you can set on the component.

The effort a programmer has to make to use these components is minimal compared to other frameworks. Please refer to the demos for a better understanding of how to use these components.

Written by Bill Anastasios Demos. Special thanks to Daniel Mauric, Tommi Prami, and Roland Bengtsson for the extensive testing and suggestions.

Source, more informantion and download NetCom7 https://github.com/DelphiBuilder/NetCom7

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---