Error reading message!

[CyaNn]

I am currently developping a new Driver to accept TCP/IP proprietary messages.
Everything runs weel during an hour until the driver stop unexpectively.

The event manage give me the following message :

Code: Select all

PVSS00TCPComm2:PVSS00TCPComm(2), 2013.04.26 09:32:40.092,DRV_USR1,driver stopping
PVSS00event  (0), 2013.04.26 09:32:40.088, SYS,  SEVERE,     39, Connection lost, MAN: (SYS: 1 Driver -num 2 CONN: 1), Error reading message! Msg dump follows:  Source: (SYS: 1 Driver -num 2 CONN: 1) Destination: (SYS: 1 Event -num 0 CONN: 1) OriginTime: 2013.04.26;09:32:40:087  RealTime: 0 MessageID: 0000003426 AnswerID: 0000000000
Hex dump follows:
50 56 53 53 ff ff ff ff a0  3  0  0  8 1a  0  0
 1  0  0  0  2  2  0  0  0  0  0  0  1  0  0  0
 1  0  0  0 62  d  0  0 b8 49 7a 51  0  0  0  0
c0 83 2f  5  0  0  0  0 ba  b  0  0 62  d  0  0
 0  0  0  0  0  0  0  0  1  0  0  0  1  0  0  0
 2  2  0  0  0  0  0  0 b8 49 7a 51  0  0  0  0
c0 83 2f  5  2  0  0  0  1  0  0  0 e8 6a  0  0
e7  9  0  0  1  0  0  0  0  0  0  0 65  0  2  0
30  1  0  0  0  0  8  0

Please can you explain me what does it means where my error come from.
Thanks in advance
Yann Caron

[mpoint]

The error tells you that the manager failed to deserialize a message it received. The dump shows the first few bytes of the received data.

50 56 53 53 -> "PVSS", magic number for messages
ff ff ff ff -> I think this is supposed to be the message length, but it seems incorrect
a0 3 -> version number 3.10

Maybe your TCP/IP proprietary messages are somehow interfering with the regular message communication?

[CyaNn]

Well, the TCP port of our propriétary communication is 5000.
We already have a java solution in the same server which use this port and we never has this problem..... :S :S :S :S :S

PS : the java interface is desactivated when I run the new solution.... of course....

[mpoint]

Or maybe the message length is correct and has overflowed. No idea if this can actually happen, or would be caught somehow. Do you find it likely that your driver is sending >= 2GB of data in one message, either just by producing a lot of data, or maybe by additionally blocking the dispatch-loop for a long time?

The dumped message seems to be a DP_MSG_COMPLEX_VC (or dpSet), if that helps.

[CyaNn]

From what you told me, I guess an architecture mistake.
The principle is the following :
A singleton object contains the servers threads
When driver has finnish to initialize the internals DPs, server are added to the singleton and then starter. I don't use th DRV object to do that.

This is the part of my code :

Code: Select all

void TCPCommResources::answer4DpId(const DpIdentifier &dpId, Variable *varPtr) {

	if (INTERNAL_DPID == isInternalDpId (dpId)) {
		PVSSDataPoint *dp = this->findDpById(dpId);

		SocketAbstract *socket = Driver::getInstance().getSocket(dp->getNumber());

		if (dp->getConfigType() == SERVER) {
			SimpleServer *server = (SimpleServer *)socket;
			if (socket == NULL) {
				server = new SimpleServer();
				server->initialize(new MessageXml('\\n'));
				Driver::getInstance().addSocket(server);
			}

			switch (dp->getUsage()) {
				case DPUsage::AGENT_ID:
					server->setAgentID(((IntegerVar*)varPtr)->getValue());
					break;
				case DPUsage::PORT_NR:
					server->setLocalPort(((IntegerVar*)varPtr)->getValue());
					server->start();
					break;
			}

		}
		
	}

	delete varPtr;
}

Is my thinking is wrong ?

[mpoint]

I don't know much about drivers, so I am probably the wrong person to ask.

[Gertjan van Schijndel]

Since the dumped message seems to be a DP_MSG_COMPLEX_VC, it would make sense to look at how you send your values to the event manager.

To my knowledge all dp-functions shoulde be called from a single thread. Otherwise you could get error messages like these.

[CyaNn]

Oh what do you call dp-function ? Is it database access ?
If it is the case, the problème I have is : clients / server TCP architecture is based on multi-thread.

The only solution I have is to put a synchronous message queue.
Threads add messages to queue and notify message manager that is on the main thread.
Message manager loop until queue is empty and wait.

Is that my reasoning is correct ?

[Gertjan van Schijndel]

With dp-functions I mean functions, that start with 'dp', like 'dpSet', 'dpConnect', 'dpGet' and 'dpQuery'. In other words functions that provide access to or modify the internal WinCC OA database.

I think that the mentioned solution will solve the problem.

[mpoint]

The WinCC OA Manager API is strictly single-threaded. In your own TCP communcation stuff you can use as many threads as you like, but basically everything that the WinCC OA API provides should only be used from a single thread.