rpo
asked on
Choosing SMTP component
I need to send email using SMTP protocol and I found few ready-to-use solutions (FastNet, Indy and Turbopower Internet Professional).
But before I pick one of them I'd like to know if anyone had any problems with them.
Stability is very imporatant for me. Much more than speed.
So, do you have any thing to say about those components.
(more points will be given for multiple answers)
But before I pick one of them I'd like to know if anyone had any problems with them.
Stability is very imporatant for me. Much more than speed.
So, do you have any thing to say about those components.
(more points will be given for multiple answers)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, thanks to both of you. I'll pick either Indy or ICS after some checks.
I accept loufeliz' comment as an answer. The same amount of points for swift99 will be available in separate question.
I accept loufeliz' comment as an answer. The same amount of points for swift99 will be available in separate question.
Thank you!
I recommend against any pseudo-blocking component - Windows network handling requires that the message pump not be blocked. A true blocking component will simply not work (once the thread is blocked it cannot receive network messages), and a pseudo-blocking component introduces the possibility of message loss and application lockup under high loading conditions.
Non-blocking components such as ICS provide higher performance and better reliability under Windows. Several thousand concurrent users have been served off of one thread using non-blocking ICS components. ICS is also fully thread safe.
The downside to a non-blocking component is that you must think like a real Object Oriented programmer, not aprocedural programmer in a component environment. This is a short but steep learning curve for most people.
If you plan to port to linux, then you must use a blocking component in your linux version. This is because linux' network handling is bound to threads rather than messaged to threads. There is a port of ICS to the linux/Kylix blocking model that is almost drop in.
ICS has been around since Delphi 1, and is supported under D1 through D7, several versions of BCB, and Kylix 1 through 3, all from the same source files. There is a project underway right now to add SSL support to the suite.
ICS is written entirely in Delphi from the Windows API to the component interfaces, and is shipped with source. The cost is one postcard with one nice stamp (The post card is for Francois, the initial author and major contributor to the code base, and the stamp is for his daughter who collects cancelled stamps.)
Support for ICS is by other users of the suite on a free mailing list.
"Throw out everything else and use ICS" was the first piece of advice anyone ever gave me on EE, and it is the single piece of advice I pass on most frequently.
ICS is available from overbyte.delphicenter.com It comes with full source code and usage examples for all components. Each component implements the full RFC specification that it embodies.
Good luck!