I am designing a control system and user interface for a model train infrastructure and I was wondering if this is the technology to use? I mean Message Passing if yes which programming language is best to use for this purpose? Has anyone got any pointers on where to start? I know some java and c#!
Many thanks
If you can put in some effort and learn WPF for interface designing, then that would be cool. Otherwise you can use windows forms in C#.NET.
You can use remoting for communication but if you are concerned with performance then you can use sockets and Google's protobuf for message contraction and serialization/deserialization. You can find a port of protobuf for .NET at http://code.google.com/p/protobuf-net/. Its super easy and fast.
Thats the most I can suggest from the the amount of information you have put in the question.
Related
Is there any tool for viewing registered types in CORBA Trading Service, and maybe, for making some simple queries for objects?
I am using TAO, if it matters.
Not that I know off. Maybe you can write your own and contribute it back to TAO. Maybe consider a scripting language for a client, like Ruby with the R2CORBA implementation which is interoperable with TAO
I have some data that I need to share between multiple services on multiple machines. Stuffing the data into a database or shuffling it over http won't work in this situation and ideally the different pieces of software will need to communicate with each other directly (or through one central coordinator that can send and receive).
Is it recommended to create and implement a network protocol or use some tool to do the communication?
If I did go the route of creating a protocol myself, it wouldn't have to be very complex. Under 10 different message types, but it would have to be re-implemented in a few different languages for this project, and support unicode. I have read plenty (and done some) with handling sockets, but don't have much knowledge in handling a protocol I create. Are there any good resources on this?
There are also things like ICE and RPC that look intresting. The limit of my experience is using ICE and XMLRPC for a few days each. Is this the better route to go? If so what tools are out there?
Recently I've been using Google Protocol Buffers for encoding and shipping data between different machines running software written in different languages. It is quite easy to do, and takes away a lot of the hassle of designing a custom protocol.
Without knowing what technologies and platforms you are dealing with, it's difficult to give you a very specific answer - so I'll try to give you some general feedback.
If the system(s) you are wishing to connect span more than a single platform and/or technology you are probably better using an existing transport mechanism and protocol to maximize the chance your base platform will already have a library (or multiple) to interact over it. Also, integrating security and other features in a stack with known behaviors is more likely to be documented (with examples floating around). RPC (and ICE, though I've less familiarity with it) has some useful capabilities, but it also requires a lot of control over the environment and security can be convoluted (particularly if you are passing objects between different languages).
With regards to avoiding polling, this is a performance related issue; there are design patterns which can help you to handle such things - if you understand how you need the system to work (e.g. the observer pattern - kind of a dont-call-us-we'll-call-you approach). The network environment you are playing in will dictate which options are actually viable (e.g. a local LAN will have different considerations from something which runs over a WAN or the internet). Factors like firewall tunneling, VPN traversal, etc. should play part in your final selected technology profile.
The only other major consideration (that I can think of just now... ;-)) would be to consider the type of data you need to pass about. Is it just text, or do you need to stream binary objects? Would an encoding format (like XML or JSON or bJSON) do the trick? You mention "less than ten message types" as part of the question, but is that the only information which would ever need to be communicated by the system?
Either way, unless the overhead of existing protocols is unacceptable you're better of leveraging established work 99% of the time. Creativity is great - but commercial projects usually benefit from well-known behaviors, even if not the coolest or slickest (kind of the "as long as it works..." approach).
hth!
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 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).
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