You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2011-08-15 15:36:18
- BeginEnd;
- Member
- Registered: 2011-01-08
- Posts: 9
Synopse vs ICS
In your code, you mentioned that Synopse is faster than indy or synapse. I think all these three are blocking sockets.
/// Fast low-level Socket implementation
// - direct access to the OS (Windows, Linux) network layer
// - use Open constructor to create a client to be connected to a server
// - use Bind constructor to initialize a server
// - use direct access to low level Windows or Linux network layer
// - use SockIn and SockOut (after CreateSock*) to read or write data
// as with standard Delphi text files (see SendEmail implementation)
// - if app is multi-threaded, use faster SockSend() instead of SockOut^
// for direct write access to the socket; but SockIn^ is much faster than
// SockRecv() thanks to its internal buffer, even on multi-threaded app
// (at least under Windows, it may be up to 10 times faster)
// - but you can decide whatever to use none, one or both SockIn/SockOut
// - our classes are much faster than the Indy or Synapse implementation
TCrtSocket = class
public
/// initialized after Open() with socket
Sock: TSocket;
...
...In ICS (commet from ICS code included below), it is claimed that it is of very high performance due to its asynchronous non-blocking behaviour.
How your socket's performance compare with ICS, mainly when using multiple connections (sockets) to achieve better speed? (like a download manager using 10 connections to download a file at top speed; instead of using a single connection like browsers do)
ICS's multi connection and your's multi thread approach (say 10 threads to DL a file) both achieve more or less same speed?
Comments from ICS code:
{
About multithreading and event-driven:
TWSocket is a pure asynchronous component. It is non-blocking and
event-driven. It means that when you request an operation such as connect,
the component start the operation your requested and give control back
immediately while performing the operation in the background automatically.
When the operation is done, an event is triggered (such as
OnSessionConnected if you called Connect).
This asynchronous non-blocking behaviour is very high performance but a
little bit difficult to start with. For example, you can't call Connect and
immediately call SendStr the line below. If you try, you'll have an
exception triggered saying you are not connected. Calling connect will start
connection process but will return long before connection is established.
Calling SendStr at the next line will not work because the socket is not
connected yet. To make it works the right way, you have to put your SendStr
in the OnSessionConnected event.
The asynchronous operation allows you to do several TCP/IP I/O
simultaneously. Just use as many component as you need. Each one will
operate independently of the other without blocking each other ! So you
basically don't need multi-threading with TWSocket, unless YOUR processing
is lengthy and blocking.
If you have to use multithreading, you have two possibilities:
1) Create your TWSocket from your thread's Execute method
2) Attach a TWSocket to a given thread using ThreadAttach.
In both cases, you must set MultiThreaded property to TRUE.
If you don't use one of those methods, you'll end up with a false
multithreaded program: all events will be processed by the main tread !
For both methods to work, you MUST have a message loop withing your thread.
Delphi create a message loop automatically for the main thread (it's in
the Forms unit), but does NOT create one in a thread ! For your convenience,
TWSocket has his own MessageLoop procedure. You can use it from your thread.
Sample program MtSrv uses first method while ThrdSrv uses second method.
Sample program TcpSrv is much the same as ThrdSrv but doesn't use any
thread. You'll see that it is able to server a lot of simultaneous clients
as well and it is much simpler.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
...Last edited by BeginEnd; (2011-08-15 15:38:35)
Offline
#2 2011-08-15 18:31:19
Re: Synopse vs ICS
For 10 or 100 connections at once, blocking and not blocking mode won't make any difference, IMHO.
Historically, asynchronous synchro was necessary (under DOS or Windows 16 bit), because such OS didn't have sufficient memory resource.
Now, the bottleneck is not the HW any more, but the SW, more precisely the API layer.
You can still develop slow implementations (like WinINET).
The firewall or the anti-virus/anti-spyware tools are major PITA for the socket implementation, under Windows.
I suspect our WinHTTP (on client side) will be faster than Synapse or Indy, perhaps not faster than ICS with 100ths of client connections.
And that WinAPI/http.sys (for server side) will be faster than any other implementation (it's running in kernel mode, in asynchronous way) - even ICS.
To be honnest, if you run a client/server HTTP benchmark locally (on the same computer), e.g. our TestSQLite3.dpr, you'll see that our HTTP is slowest than other protocols (named pipes, GDI or direct connection), but will still be faster than HW: more than 1 Gb/s can be served.
You'll have to use real benchmark to test which one is faster, and which one fit your need.
IMHO you won't notice any diff on remote Internet-based server. The bottleneck won't be your app.
And if you want something fast, consider using a Linux OS without any graphical layer and with tuned network settings, and a "smart" network card. In this case, you'll get tremendous perfs.
There is not "absolute faster" component, IMHO.
Depeding on benchmark or network configuration, it will always depend.
Only apps which fit a particular purpose... or not...
Offline
#3 2011-08-27 08:18:28
- BeginEnd;
- Member
- Registered: 2011-01-08
- Posts: 9
Re: Synopse vs ICS
the Thread Pool facility is available only if I am going to use a HTTP based class (say THttpServer)
What if I need thread pool when I am using only direct socket class? (i.e TCrtSocket)
Can you provide a class/function to achieve this?
Offline
Pages: 1