I never liked components for winsock programming,I loved it in its natural way,but today my collegue told me to use Indy for my project.Could you tell me if Indy better alternative for my project?
-2 TCP servers,2 TCP clients.4 sockets total
-The project is a proxy.
And now the second question,I read daily that WSAASyncSelect is not good and that's predictable,it's from winsock 1.1.My question is: Suggest something better than AsyncSelect for winsock-by-hand.
Thank you.
My preference tends to lean on synapse for all of my socket work because of its light and easy to understand approach. It is not a component architecture, but a class architecture and implementation is generally as simple as copying one of the existing helper classes and modifying it to perform the exact steps needed. Synapse also has a great user community, and is being actively developed so get the latest changes from the svn snapshot (I believe its revision 98, the website has a zip of revision 38).
Yes, Indy is much better because it provides you with consistent abstraction of winsock communication. The difference is like creation windows using WinApi and simply using TForm.
Yes, Indy is better. So is ICS, or Synapse, or any of the other internet-related component sets. They handle all of the minutia and let you work on your application's actual functionality instead of wasting your time on the communications layer details. They're also much more well tested (because of the broader user base and wider range of hardware and operating systems) than your own code could ever hope to be.
NIH (Not Invented Here) is a really bad idea if there are well-constructed, well-maintained, and widely used alternatives available, especially when those alternatives are free with source (like Indy and ICS).
Related
Could someone please explain their differences? Are they same and work the same way? Which one is better than the other components?
They are NOT the same, and they DO NOT work the same way. They take very different approaches to socket API interactions, event handling, error handling, etc.
TClientSocket and TServerSocket are the original VCL-based (Windows-specific) socket components. They were deprecated in Delphi 7 and are no longer installed by default, but are still available for manual install if you want to use them.
TTcpClient and TTcpServer were originally introduced in Delphi 6 as a cross-platform socket solution for Kylix (which is a dead product). They were removed from Delphi in XE6, downgraded to demo status, not even official components anymore.
In my opinion, TTcpClient and TTcpServer are horrible components, you should stay away from them. They use a very minimalistic "least common demoninator" approach to cross-platform programming, catering only to a few basic functions that multiple platforms support, not leveraging any platform-specific features or even higher-level functions. They have a very basic interface that is badly designed. They are very difficult to work with, have bad error handling, and are not very flexible to use.
If you need to write new socket code, TClientSocket and TServerSocket work great if you are only interested in supporting Windows, but if you need to support cross-platform then you should use a third-party socket library, such as Indy (TIdTCPClient/TIdTCPServer), ICS (TWSocket/TWSocketServer), Synapse (TTCPBlockSocket), etc.
I'm figuring that CORBA is considered a legacy technology that just refuses to die. That being said, I'm curious if there are any known standards out there that are preferred (and are also as platform independent.)
Thoughts? TIA!
Many organization are moving to WebServices and the open standards relating to them (HTTP, WS-*) as alternatives to Corba.
This article provides a comparison of the two technologies and offers some recommendations on when to use which.
If you really care about platform independence and protocol standardization - then the WS-* standards are something to look into.
There is now a state of the art modern CORBA implementation using C++11, TAOX11. This uses the new IDL to C++11 language mapping. For TAOX11 see the TAOX11 website. TAOX11 is supported on a wide range of platforms and compilers.
I have recently tried Google Protocol buffers, they seem rather similar to CORBA by design (some kind of IDL with compiler, binary compact messages, etc). It is probably one of the many possible successors.
Web services are good for the right tasks but creating and parsing messages needs more time and text based messages are more bulky than binary ones. REST API with JSON looks like a good solution where binary protocols do not fit well.
ICE from ZeroC aims to be a "better CORBA".
Unfortunately their licensing terms are crap (at least last time I checked with them), as they do not sell developer licenses but only (roughly) per-installation terms.
It is offered via GPL license too, if you can live with this.
I want to connect two PCs and have them communicate. Is there a nice component to do that? (preferably from TMS, or free), or do I just use standard C++ socket libraries?
What about sending data? Should I invent a simple protocol? TLV (type/length/value), where T is the message type and .. you get the picture...
Since you are using C++ Builder, you should really be using the Indy components, they are a nice well tested and easy to work with set of networking components... And they are already built into C++ Builder. If you are using C++ Builder, using Qt or boost can be really problematic (of course depending on C++ Builder version).
Indy components: http://www.indyproject.org/index.en.aspx
With Indy components you get all the components you need for basically every sort of network development you need, it is by far the most complete networking solution for C++Builder/Delphi that I have seen.
You might find this article interesting: Developing TCP/IP-based Server Applications using Indy Components [1] it shows examples in Delphi, but converting to C++ should be trivial.
Besides the Delphi in Depth [2] book is a good resource and contains samples in C++ as well.
About the developing your own protocol, it is almost impossible to answer that question with a definitive answer, it really depends on the requirements you have. Perhaps you should start by asking, is there an existing protocol that would work for me, before you end up, perhaps, reinventing the wheel.
[1] http://conferences.embarcadero.com/article/33256
[2] http://www.atozed.com/indy/book/index.en.aspx
You should look at Qt or Boost. (I personally prefer Qt's network API and documentation, but you may feel differently.)
And for something simple, why would you invent your own protocol? Just use HTTP. It's easy to work with and you can use all kinds of tools, not just your own code, to verify that everything is working properly.
I need a few of my related applications to communicate to each other (exchange data and initiate actions). Requirements are without packages and no sockets. So I guess that leaves named pipes, WM_CopyData (like Skype does it) and command parameters. What are your best practices?
You probably have a couple of options.
Beyond what you already have:
DDE
Memory Mapped Files (MMF)
MailSlots
I would probably go with either the Pipes or the MMF.
There are a couple of free MMF components that you can download,
Deborah Pate has a set of freeware classes you can use.
MapFiles.zip
Check for MailSlots on Torry's site.
The final solution might be dependent on the amount, size and frequency of the data transfers that decide which option you choose.
I would advise to use COM in this situation. (Attention: not COM+, not ActiveX, not OLE; COM, just COM.)
Since Delphi 7 (or an earlier version, I'm not sure), this is easily done by adding a Type Library to the project, and an Automation object.
Advantages are it's pretty widely supported, both within Delphi (the Type Library Editor has everything you need and updates your code, and COM internals and registering are catered for from the ComServ unit), and outside of Delphi (I use it in a number of project to interact with all sorts of applications: C++ projects, Word and Excel documents using VBA, oldskool ASP...).
An only disadvantage I encountered may be threading issues, in normal applications, a plain CoInitialize(nil); at application startup will do, in more complex applications, you need to think about 'threading apartments' or use free threading and do your own locking. (Which in some cases you've been doing already.)
Another alternative which is dirt simple to implement is to use the database to pass information.
Not overly elegant, and it does use a lot of overhead, but if your application is already data-aware (ie has a database as part of it), then using a table or two to pass information is pretty easy.
You could use simple files: One side writes to it, the other reads. If you need two way communication, just use two files, one for each direction.
Of course this is not really high performance.
Another vote from me for named pipes, for the data exchange. I like them slightly more than mmap files, since the win32 pipe APIs give you some nice choices out of the box: sync/async, byte stream vs message packets, simple ReadFile/WriteFile calls. All of which you could do yourself with mmaps... but pipes are already there...
And you can control access with security attributes -- which isn't an option with WM_CopyData. This might not be an issue immediately... but can be handy to have the option, even if you don't care who sends your app messages. For me, this was helpful when Vista came along, and suddenly user apps ran in a separate session to my service. Was good that tweaking the security attributes was the only thing needed to get things working again.
For "initiating actions", you might be able to get away with something as easy as some named Events, and not worry about sending messages at all? The interested parties simply wait for it to be signalled.
Personally, I'd avoid COM unless you have to specifically support COM-based clients.
Do not use COM, too much overhead (variants) and you must register you .dll or .exe (and it gives a lot of weird installation + update problems).
I should go for MMF, I use this for communication with Windows Services.
I use the following TGpMessageQueueReader and writer for this:
http://17slon.com/gp/gp/gpsync.htm
If you want to pass data, call functions etc then use COM, however if there are lots of calls be aware that COM is slow. Also you might have to register the application with "xxx.exe /Regserver", before it will work.
Is'nt this the sort of this that RemObjects is good at?
Bri
I need to deploy a Delphi app in an environment that needs centralized data and file storage system (for document imaging) but has multiple branch offices with relatively poor inter connectivity. I believe a 3 tier database application is the best way to go so I can provide a rich desktop experience with relatively light-weight data transfer needs. So far I have looked briefly at Delphi Datasnap, kbmMW and Remobjects SDK. It seems that kbmMW and Remobjects SDK use the least bandwidth. Does anyone have any experience in deploying any of these technologies in a challenging environments with a significant number of users (I need to support 700+)? Thanks!
Depends if you are tied to remote datasets. If you aren't dataset bound then SOAP would likely be a good choice. Or, what I've done is write my own protocol that is similar to SOAP in nature. This was done before SOAP was standard and I'm glad I did - this gives you the ability to control more of the flow of data. It's given that if you have poor connectivity then you will be spending time supporting it. It's very nice if it's your own code you are supporting versus having to wait on a vendor. (Although KBM and REM are known to be pretty good vendors.)
Personal note: 700 users in a document imaging application over poor connectivity sounds like a mess. Spend the money on upgrading connectivity as it'll be cheaper in the long run.
Both kbmMW and RO SDK offer binary format, which is more compact than SOAP format,specially you are working with documents.
RO sdk seems to offer more GUI tools to help you doing your services.
Also give a RealThinClient SDK a look, it's a lightweight remoting framework.
But what ever framework you go with, your design of work will make it fast or slow, I have some applications working on slow 128kb lines, and it's working perfect without any user complain, but I don't do a large transfer for files.
One thing to remember...its not the number of users, but the number of them using the resources at the same time that will be the issue. Attempt to develop your application "server stateless" if at all possible, this will allow greater flexibility in the long term if you find you have to add more servers to the pool to support your customer base. The hardest thing about n-tier is scaling beyond the first server...plan on that from the start. Each request should not know anything about a prior request...or at the very least the request should have a way of passing the context so the server can look it up in a session table or something.
Personally, I would recommend RemObjects. I have used it with good results.
I don't know if it's the very best / most efficient (glad you asked this question!), but I've had good results w/RemObjects SDK + DataAbstract. The latter made much of the plumbing details less involved, which was helpful. Still implementing, but so far so good.
If you really wanna go "low-bandwidth" use BSD Sockets API - that'll give you full control over what's being sent and there you can send as little information as you want. Of course then you'll have to implement all the tiers yourself, but hey - that's still an option :D