Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have my own OPC Server written using the SLIK-DA4 ActiveX control in VB6. It hosts quite a large collection of tags (probably 2,000).
A customer uses a Siemens OPC client to connect (no private security). Everything goes fine and subscription reads appear just fine on the client.
Some time later, the IP link is lost between client and server for a while. However, the customer is telling me that when the link recovers, they then have to "do something" on the OPC client to get it to start subscribing again, after which things return to normal.
... Yes, I know, I'm trying to find out what they mean by "do something" !!
However, in the meantime, I'm trying to think of what I might not be doing correctly in my server code to handle this situation. My tag values don't update too often in the attached field equipment, so is it possible that, on reconnection, the client isn't receiving any callbacks simply because there are no tag changes taking place ?
On recovery of the link, how can I get the server to push an up-to-date status for all tags to the client rather than rely on someone "doing something" on the client end ? Do I need to use the OnConnect event and then SetVQT(,,sdaSGood) for all tags, or will this not have any effect ?
Thanks
When the OPC server receives a new connection (which seems to be the case), or more precisely, when the OPC client it creates an active group and puts items in it, the server is supposed to send an initial notification about each item (value/timestamp/quality, or error) - even if it has not changed recently.
If you are developing the server using a reasonable OPC toolkit, however, this should be taken care of automatically by the toolkit code. It certainly makes no sense to try to change the quality of the tags just because the OPC client had connected. The quality in the VQT should reflect whatever comes from your underlying system, or the communication problems communicating to THAT system, but not anything between the OPC server and the client.
It may also very well be a problem on the client side - simply not resilient enough to handle certain situations. The authoritative way to tell what is happening (and put the "blame" into the direction of the server or the client) would be place an OPC Analyzer (available from OPC Foundation to OPC Members) in between, and log the OPC calls and check which side is not behaving right.
what they mean by "do something"
I think it means that customer needs to restart the client, create a group and add tags. But this is how things should be, because OPC Specification doesn't say anything about handling of connection breaks. It has only description of interfaces which can be used to check connection (server) status (e.g. IOPCServer::GetStatus). Typically, clients reconnect (create a new connection with new group and add tags) automatically, but only if they have been noticed that connection was lost.
a "re-open" request from their OPC Client
You can ask someone from Siemens to provide you quotation from OPC Specification where "re-open" mechanism and/or interfaces are described. Because I don't remember such notations in specification.
But if "re-open" means reusing of old connection (i.e. DCOM objects left from old connection) then I may assume the following situation:
client and server interacts properly
connection breaks
server sends OnDataChange callback to client and receives an error (something like "RPC service is unavailable")
server just stops sending of OnDataChange callbacks and do nothing with DCOM objects related to current connection
connection restores
client still can call server using existing DCOM objects but doesn't receive OnDataChange callbacks
customer need to restart client manually to repair connection
In such case you (or toolkit) should remove all objects related to broken connection or don't stop sending of callbacks.
When IP changes ,try to reconnect the OPC Server or Make your OPC Server IP address as static
Related
I created a client application that has a subscription to monitor several tags through the OPC UA server(c#). If the connection between the OPC server and the PLC is lost while the client is running, the client stops receiving information from the server and it is never notified that the plc is not reachable any more.
I am evaluating to implement a periodic reading operation for one tag through the OPC server to actually know if the plc connection is active or not, but if there is a native mechanism in OPC UA I would like to avoid it.
Is there a way (eg. an event) to notify the client that the connection with the plc is lost for the running subscription?
A compliant OPC UA server must send notification with one of the "Bad" status codes, when the connection to the target system is lost. This is the normal notification event, same channel as the "good" ones, it just carries a different DataValue that happens to have the StatusCode with corresponding bits set so that it indicates a problem.
So, you need to check the StatusCode in the incoming notifications. If you are already doing that, but the server truly sends nothing in case of communication loss, you need to complain to the server vendor, because such behavior isn't really acceptable for any serious server.
Note: There are ways to specify a data change "filter" when subscribing to monitored item, and you can tell whether you want to be notified e.g. when just the timestamp changes and not the value, etc. But no matter how the filter is set, changes in StatusCode are always sent. Therefore the problem cannot be in having incorrect filter set.
I'm trying to enhance a server-app-website architecture in reliability, another programmer has developed.
At the moment, android smartphones start a tcp connection to a server component to exchange data. The server takes the data, writes them into a DB and another user can have a look on the data through a website. The problem is that the smartphones very regularly are in locations where connectivity is really bad. The consequence is that the smartphones lose the tcp connection and it's hard to reconnect. Now my question is, if there are any protocols that are so lightweight or accomodating concerning bad connectivity that the data exchange could work better or more reliable.
For example, I was thinking about replacing the raw TCP interface with a RESTful API, but I don't really know how well REST works in this scenario, as I don't have any experience in this area.
Maybe useful to know for answering this question: The server component is programmed in c#. The connecting components are android smartphones.
Please understand that I dont add some code to this question, because in my opinion its just a theoretically question.
Thank you in advance !
REST runs over HTTP which runs over TCP so it would have the same issues with connectivity.
Moving up the stack to the application you could perhaps think in terms of 'interference'. I quite often have to use technical stuff in remote areas with limited reception and it reminds of trying to communicate in a storm. If you think about it, if you're trying to get someone to do something in a storm where they can hardly hear you and the words get blown away (dropped signal), you don't read them the manual on how to fix something, you shout key words such as 'handle', 'pull', 'pull', 'PULL', 'ok'. So the information reaches them in small bursts you can repeat (pull, what? pull, eh? PULL! oh righto!)
Can you redesign the communications between the android app and the server so the server can recognise key 'words' with corresponding data and build up the request over a period of time? If you consider idempotency, each burst of data would not alter the request if it has already been received (pull, PULL!) and over time the android app could send/receive smaller chunks of the request. If the signal stays up, just keep sending. If it goes down, note which parts of the request haven't been sent and retry them when the signal comes back.
So you're sending the request jigsaw-style but the server knows how to reassemble the pieces in the right order. A STOP word at the end tells the server ok this request is complete, go work on it. Until that word arrives the server can store the incomplete request or discard it if no more data comes in.
If the server respond to the first request chunk with an id, the app can use the id to get the response and keep trying until the full response comes back, at which point the server can remove the response from its jigsaw cache. A fair amount of work though.
The server consists of several services with which a user interacts: profiles, game logics, physics.
I heard that it's a bad practice to have multiple client connections to the same server.
I'm not sure whether I will use UDP or TCP.
The services are realtime, they should reply as fast as possible so I don't want to include any additional rerouting if there are no really important reasons. So are there any reasons to rerote traffic through one external endpoint service to specific internal services in my case?
This seems to be multiple questions in one package. I will try to answer the ones I can identify as separate...
UDP vs TCP: You're saying "real-time", this usually means UDP is the right choice. However, that means having to deal with lost packets and possible re-ordering of packets. But, using UDP leaves a couple of possible delay-decreasing tricks open.
Multiple connections from a single client to a single server: This consumes resources (end-points, as it were) on both the client (probably ignorable) and on the server (possibly a problem, possibly ignorable). The advantage of using separate connections for separate concerns (profiles, physics, ...) is that when you need to separate these onto separate servers (or server farms), you don't need to update the clients, they just need to connect to other end-points, using code that's already tested.
"Re-router" (or "load balancer") needed: Probably not going to be an issue initially. However, it will probably become an issue later. Depending on your overall design and server OS, using UDP may actually become an asset here. UDP packet arrives at the load balancer, dispatched to the right backend and that could then in theory send back a reply with the source IP of the load balancer.
An alternative would be to have a "session broker". The client makes an initial connection to a well-known endpoint, says "I am a client, tell me where my profile, physics, what-have0-you servers are", the broker considers the current load, possibly the location of the client and other things that may make sense and the client then connects to the relevant backends on its own. The downside of this is that it's harder (not impossible, but harder) to silently migrate an ongoing session to a new backend, when there's a load-balancer in the way, this can be done essentially-transparently.
I'm working on a personal project. It's to recreate server software for the game "Chu Chu Rocket" for the Sega Dreamcast. Its' servers went down in 2004 I believe. My approach is to use dnsmasq to change the originl hostname that the game originally connected to, to my own system. With a DC-PC server set up, I have done just that, now instead of it looking up a non-existent dns record, it connects to my computer which will eventually run the server software. I've used tshark (cli wireshark) to capture what's going on between the client (dreamcast) and the server (my computer). The problem is, I'm getting data, but I'm not sure how to interpret it, I don't know what it's saying, but I'm sure it can be done because private PSO servers were created, those are far more complex.
Very simply, where would I go about learning how to interpret data packets, and possibly creating packets that will respond to such queries from the client?
Thanks,
Dragos240
If you can get the source code for the server software on your PC, then that is the best place to look.
Otherwise, all you can do is look at the protocol, compare runs, and make notes of similarities and differences. With any luck, the protocol won't be encrypted.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm looking to establish some kind of socket/COMET type functionality from my server(s) to my iPhone application. Essentially, anytime a user manages to set an arbitrary object 'dirty' on the server, by say, updating their Address.. the feedback should be pushed from the server to any clients keeping a live poll to the server. The buzzword for this is COMET I suppose. I know there is DWR out there for web browser applications, so I'm thinking, maybe it's best to set a hidden UIWebView in each of my controllers just so I can get out of the box COMET from their javascript framework? Is there a more elegant approach?
There are a couple of solutions available to use a STOMP client.
STOMP is incredibly simple and lightweight, perfect for the iPhone.
I used this one as my starting point, and found it very good. It has a few object allocation/memory leak problems, but once I got the hang of iPhone programming, these were easy to iron out.
Hope that helps!
Can you use ordinary TCP/IP socket in your application?
A) If yes then definitely a raw TCP/IP socket is more elegant solution. From your iPhone app you just wait for notification events. The socket is open as long as your application is open. If you want you can even use HTTP protocol / headers.
On the server side you can use some framework to write servers which efficiently handle thousands of open TCP/IP connections. e.g Twisted, EventMachine or libevent. Then just bind the server main socket to http port (80).
The idea is to use a server which keeps just a single data structure per client. Receives update event from some DB application and then pushes it to right client.
B) No, you have to use Apache and http client on iPhone side. Then you should know that whole COMET solution is in fact work around for limitations of HTTP protocol and Apache / PHP.
Apache was designed to handle many short time connections. As far I know only newest versions Apache (mpm worker) can handle efficiently big number of opened connection. Previously Apache was keeping one process per connection.
Web browsers have a limit of concurrent open connections to one web server (URL address in fact, eg. www.foo.com, not IP address of www.foo.com). And the limit is 2 connections. Additionally, a browser will allow only for AJAX connections to the same server from which the main HTML page was downloaded.
I wrote a web server for doing exactly this kind of thing. I'm pushing realtime updates through the server with long polling and, as an example, I had safari on the iPhone displaying that data.
A given instance of the server should be able to handle a few thousand concurrent clients without trying too hard. I've got a plan to put them in a hierarchy to allow for more horizontal scaling (should be quite trivial, but doesn't affect my current application).
WebSync has a javascript client that works on the iPhone, if that's what you're after
Would long-polling work for what you want to achieve? You can implement the client-side in a few lines of regular Javascript, which will be lighter than any framework could possibly be.
It would also be trivial to implement it in ObjC (connect, wait for a response or timeout, repeat)
The answers to my question Simple "Long Polling" example code? hopefully explain how extremely simple Long Polling is..
Basically you would just request a URL as usual - the web-server would accept the connection, but not send any data until it's available. When you receive data, or the connection times-out, you reconnect (and repeat)
The most complicated bit would be server server-side, as you cannot use a regular threaded web-server like Apache, although this is also the case with Comet..
StreamHub Comet Server works with the iPhone out of the box, no plugins or anything required. Just browsed to their website on my iPhone and all the examples worked, didn't need to install Flash or anything.
Do you want/have do the communication for your app over http? If not, you can use CFNetwork framework to use sockets (TCP/UDP) to allow your app and server to communicate. From what I have seen of the CFNetwork stack, it is pretty cool, and makes it fairly straitforward to read and write to streams, and allows for synchronous and asynchronous communication. It also allows for you to define callbacks on your socket allowing you to get notified of events like data received, connection made, etc. So, in your example you could send the information over the socket to your server, and then you could define a callback that would listen for incoming data on the stream and then update your app accordingly.
EDIT: Did a little more research, and if you go the socket approach, you may want to also look at the NSStream classes. They are Cocoa abstractions build on top of the CFSocket stuff.
you didn't mention what serverside tech you're using. But in case it's microsoft .net (or for any other googlers who come across this), there is a simple option for comet: http://www.codeplex.com/ncomet.
COMET, LightStreamer, AJAX all that junk is broken. It is basics of TCP that no 'keep-alives' are ever guaranteed without pinging traffic.. So you can forget that long-polling if any decent reliability or timely delivery is to be guaranteed..
It's just hype everyone saw through back in 2003 when the lame-mania kicked off..