So I don't have much experience with Modbus but my problem is essentially what's in the title. Would I need a controller that talks to the box and then reformat the message and pushes it to the server? Or can the server talk to the box directly? BTW, my cloud app uses Rails if that helps. I'm not sure what other information is required so feel free to let me know.
Thanks.
All you need is a MODBUS library for Ruby.
Modbus originated as a serial master/slave protocol with two different modes; 'ASCII' and 'RTU'. The different modes have different packet formats (one uses ASCII characters, and the other uses binary), different rules for detecting the start and end of packets, and different error detection (checksum or CRC). Modbus over TCP/IP basically takes the 'RTU' packet, discards the CRC, adds some extra addressing, and wraps it up in a TCP packet. Provided you are happy to implement the code to construct (and interpret) packets in your cloud app then there's no reason why the server cannot talk to the box directly.
One thing you should bear in mind is that a 'Modbus client' issues commands to a 'Modbus server', which then responds. So you need to work out whether your box is a 'Modbus client' or 'Modbus server'.
The only thing I'm not sure about is IP addresses. If your cloud-based server gets a different IP address each time it runs then that might be a problem if it is acting as the 'Modbus server', or if your box has an access control mechanism.
All the documentation can be downloaded from www.modbus.org
Related
I want to write a app which will run on different computers and need all of then to communicate with each other like "utorrent" (peer to peer). This app only will send text messages.
How can I do this? I mean sending one message to remote computer on the internet?
I have a website and every app at start can send some information to it and find information of other apps on other computers (with PHP) but I do not know how address one computer through internet and send the data directly to that. I can find the ip address with PHP but it is the ip address of router (ISP).
How a message reaches a computer? I'm wondering about addressing every computer?
My brain really stuck here, I really appreciate any help. Thanks.
In a peer-to-peer network there's no centralized server for transmitting the data from one client to another, in this case the clients must be able to act as both the server and client. This means that either you'll have to be using UPnP like most modern torrent clients, which handles port forwarding in the router, or you'll have to manually forward a port to the computer in the router.
A centralized server (like a torrent tracker) is usually used to make the clients aware of each other's existence and tell them where to connect. This is where your PHP script comes in, though PHP might not offer the most effective way of doing this, assuming you're using it in combination with a webserver to serve the data though the http protocol.
As for actual text communication, you could use the Indy socket library for that. I found this example, basically which shows how to do it: http://www.ciuly.com/delphi/indy/indy-10-client-server-basic-demo/
I have a server application that receives some special TCP packet from a client and needs to react to it as soon as possible by sending an high-level ACK to the client (the TCP ACK won't suite my needs).
However, this server is really network intensive and sometimes the packet will take too long to be sent (like 200ms in a local network, when a simple server application can send it in less than 1ms).
Is there a way to mark this packet with a high-priority tag or something like that in Delphi? Or maybe with the Win32 API?
Thanks in advance.
EDIT
Thanks for all the answers so far. I'll add some details. My product has the following setup: there are several devices that are built upon vehicles with WIFI conectivity. When they arrive at the garage, those device connect to my server and start to transmit data.
Because of hardware limitations, I implemented a high-level ACK to make the device aware that the last packet arrived successfully (please, don't argue about this - the data may be broken even if I got a correct TCP ACK). However, if I use my server software, that communicates with a remote database, to issue this ACK, I get very long delay (>200ms). If I use an exclusive software to do this task, I get small latencies (<1ms). So, I was imagining if I could just tell Windows to send those special packets first, as it seems to me that this package is getting delayed so the database ones can get delivered.
That's the motivation behind my question.
EDIT 2
As requested: this is legacy software and I'm using the legacy dclsockets140.bpl package and Delphi 2010 (14.0.3593.25826).
IMO it is very difficult to realize this. there are a lot of equipment and software involved. first of all, if you communicate between 2 different OS's you got a latency. second, soft and hard firewalls, antiviruses, everything is filtering/delaying your package.
you can try also to 'hack' the system(this involve some very good knowledge on how the frames/segments are packed/send,flow control,congestion,etc), either by altering it from code, either by using some tools like http://half-open.com/ or others.
In short, passing MSG_OOB flag to the send function marks the data as "urgent". Detailed discussion about the OOB in the context of Windows Sockets implementation specifics is available here.
I have a custom pair of client/server sockets (TJDServerSocket and TJDClientSocket) which wrap the TServerSocket and TClientSocket in the ScktComp unit. I don't have any issues to fix, but would like to know something. I'd like to add a feature to the client side to automatically search the network for any instances of a server socket (specifically my server component).
I'm open to any suggestions, but has to be specific to the use of the ScktComp unit in Delphi 7.
Here's a link to the components of mine.
Never used the TServerSocket and TClientSocket myself, and I don't have the help files within reach, so I can't immediately see if this would work with those components.
For a project I did I needed something like that too. I ended up with using UDP to broadcast a discovery request (within the same subnet of course). The server, listening on a particular port for such a request, would reply its data back. When multiple servers would exist (a situation that though rare could occur) the client just picked the server with the required service(s) and the least load. That load was part of the data the server send back.
It worked out nice, wasn't all that difficult to write, and turned out reasonably efficient too.
The request protocol is completely up to you. The one I devised allowed clients to send a request detailing the services they need, and servers replying listing their services and the load (= connected clients in active use).
After selecting the server to talk to, a client would register itself for the services it needed, and could use them after that.
Hope this helps.
There are some standard protocols for service discovery. See for example: http://en.wikipedia.org/wiki/Zero_configuration_networking
Mailslots is a nice option here. It'll broadcast to every PC on your subnet. See Jeroen's answer to this question:
Suggestions on writing a TCP IP messaging system (Client/Server) using Delphi 2010
Searching is as easy as port scanning.
If you don't like the brute force approach, the server can register itself to a well known service application (could be a web server), and the client can connect to the service application to ask. It's quieter than broadcasting.
With more information, such as details about the network (who's it for?), I can suggest a more precise answer.
I would like to write a messaging system using TCP IP in Delphi 2010. I would like to hear what my best options are for using the standard delphi 2010 components/indy components for doing this.
I would like to write a server which does the listening and forwarding of messages to all machines on the network running a client.
1.) a.) clients can send a message to server to be forwarded to all other clients
b.) clients listen for messages from other senders (via server) and displays messages.
2.) a.) Server can send a message to all clients
b.) Server forwards any messages from clients to all other clients
thanks for any suggestions
NOTE: I am not writing a instant messaging or chat program. This is merely a system where users can send alerts/messages to other users - they can not reply to each other! NO commercial, shareware, etc links - please! I would like to hear about how you would go about writing this type of system and what approachs you would take, and possibly the TCP IP messaging architecture you would use. Whether it be straight Winows API, Indy components, etc, etc.
If this is Windows only, and you don't want to use 3rd party libraries, then you can skip TCP/IP and go for Mailslots.
Edit: if you want guaranteed delivery, than named pipes is a better solution. This SO question has a few nice answers with Delphi named pipe examples.
A mailslot is a mechanism for one-way
interprocess communications (IPC).
Applications can store messages in a
mailslot. The owner of the mailslot
can retrieve messages that are stored
there. These messages are typically
sent over a network to either a
specified computer or to all computers
in a specified domain. A domain is a
group of workstations and servers that
share a group name.
They don't need a Windows domain, they work over a LAN.
DelphiPages has a nice run-down on doing IPC in Delphi, including mailslots.
--jeroen
If you want save yourself some work and use ready solution:
0MQ
STOMP
AMQP
XMPP
in above order. Last two listed rather in informational purposes.
IMO 0MQ it's best bet - it's well-thought-out, lightweight, fast and reliable.
Looks like publish-subscribe messaging. kbmMW offers one.
There's an instant message client from Aid Aim:
http://www.aidaim.com/products/msgcommunicator/manual_instant-messaging-im-sdk/index.php
About using indy, such as in this demo: indy10clieservr.sourceforge.net OR using the TServerSocket and TClientSocket package
-> now with x64 demo sample from INDY
To get this working reliably is more work than you might think - about 5% effort to get it working, and 95% effort to ensure it works under all circumstances, including network dropouts, etc. If you go here (http://www.csinnovations.com/framework_delphi.htm) you can see how I implemented my inter-process communications framework. The TCP stuff comprises about 10,000 lines of code using the Indy components.
I need to use one logical PGM based multicast address in application while enable such application "seamlessly" running across several different geo-locations (i.e. think US/Europe/Australia).
Application is quite throughput (several million biz. messages a day) and latency demanding whith a lot of small but very frequently send messages. Classical Atom pub will not work here due some external limits of latencies.
I have come up with several options to connect those datacenters but can’t find the best one.
Options which I have considered are:
1) Forward multicast messages via VPN’s (can VPN handle such big load).
2) Translate all multicast messages to “wrapper messages” and forward them via AMQP.
3) Write specialized in-house gate which tunnels multicast messages via TCP to other two locations.
4) Any other solution
I would prefer option 1 as it does not need additional code writes from devs. but I’m afraid it will not be reliable connection.
Are there any rules to apply for such connectivity?
What the best network configuration with regard to the geographical configuration is for above constrains.
Just wanted to say hello :)
As for the topic, we have not much experience with multicasting over WAN, however, my feeling is that PGM + WAN + high volume of data would lead to retransmission storms. VPN won't make this problem disappear as all the Australian receivers would, when confronted with missing packets, send NACKS to Europe etc.
PGM specification does allow for tree structure of nodes for message delivery, so in theory you could place a single node on the receiving side that would in its turn re-multicast the data locally. However, I am not sure whether this kind of functionality is available with MS implementation of PGM. Optionally, you can place a Cisco router with PGM support on the receiving side that would handle this for you.
In any case, my preference would be to convert the data to TCP stream, pass it over the WAN and then convert it back to PGM on the other side. Some code has to be written, but no nasty surprises are to be expected.
Martin S.
at CohesiveFT we ran into a very similar problem when we designed our "VPN-Cubed" product for connecting multiple clouds up to servers behind our own firewall, in one VPN. We wanted to be able to run apps that talked to each other using multicast, but for example Amazon EC2 does not support multicast for reasons that should be fairly obvious if you consider the potential for network storms across a whole data center. We also wanted to route traffic across a wide area federation of nodes using the internet.
Without going into too much detail, the solution involved combining tunneling with standard routing protocols like BGP, and open technologies for VPNs. We used RabbitMQ AMQP to deliver messages in a pubsub style without needing physical multicast. This means you can fake multicast over wide area subnets, even across domains and firewalls, provided you are in the VPN-Cubed safe harbour. It works because it is a 'network overlay' as described in technical note here: http://blog.elasticserver.com/2008/12/vpn-cubed-technical-overview.html
I don't intend to actually offer you a specific solution, but I do hope this answer gives you confidence to try some of these approaches.
Cheers, alexis