Eclipse Community Forums: 4DIAC - Framework for Distributed Industrial Automation and Control

Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Server disconection(Unexpected silent server disconection behaviour)

Show: Today's Messages :: Show Polls :: Message Navigator

Server disconection [message #1757827]

Mon, 20 March 2017 11:54

Adrian Orive

Messages: 38
Registered: March 2017

Member

While looking at the communication infrastucture source, I found a feature that is probably not intended.

commfb.cpp (lines 72-112)

At line 108 eResp is being checked against e_Terminated, that matches e_InitTerminated. In case it is an e_Server you are setting eResp = e_Nothing saying servers will not send information on client termination and should silently start to listen again while what is actually silently bypassing is Server termination, not client ones.

Demostration:

The server before triggering INIT
Step 0

The server after triggering INIT with QI = FALSE: as it can be seen, the output is the same that in the previous image. closeConnection() is being called but as no connection was opened it does nothing, then eResp is set to e_InitTerminated and then back to e_Nothing, so the output data is not even being updated nor the output events triggered.
Step 1

The server after triggering INIT with QI = TRUE: the server is properly initialised.
Step 2

The server after triggering INIT with QI = FALSE: a server shutdown would be expected and the connection gets closed properly as this time we do have an open conection. But the second part, setting and unsetting eResp and not updating the output data nor triggering the output events make the application unaware of this disconection.
Step 3

What I think lines 108 to 117 were trying to do is detect some kind of error either on RSP or external events. Maybe eResp should have been e_ProcessDataNegative or some other error code but not e_Terminated as this turns Server disconnections quiet, not client errors.

Attachment: commfb_cpp_72-112.PNG
(Size: 50.78KB, Downloaded 374 times)
Attachment: ServerStep0.PNG
(Size: 11.65KB, Downloaded 248 times)
Attachment: ServerStep1.PNG
(Size: 11.90KB, Downloaded 255 times)
Attachment: ServerStep2.PNG
(Size: 12.55KB, Downloaded 260 times)
Attachment: ServerStep3.PNG
(Size: 12.08KB, Downloaded 254 times)

Report message to a moderator

Re: Server disconection [message #1757849 is a reply to message #1757827]

Mon, 20 March 2017 15:22

Adrian Orive

Messages: 38
Registered: March 2017

Member

Slightly related to this issue, I found that in ipcomlayer.cpp e_InitTerminated is being used 4 times, 3 of them (lines 51, 57 and 63) inside the sendData() function and the last one inside handledConnectedDataRecv() function that only gets called from inside recvData(). This does not comply with Holobloc's Compliance Profile.

This is not the only return code that is not complying, as attaching a WSTRING to the SUBSCRIBE_X FB instead of STRING was not returning an INVALID_OBJECT or a DATA_TYPE_ERROR as you could expect from that table, but a TERMINATED.

I'm not sure if that Compliance Profile is being applied in 4DIAC but at least some clean-up would be nice.

Report message to a moderator

Re: Server disconection [message #1757866 is a reply to message #1757849]

Mon, 20 March 2017 21:28

Alois Zoitl

Messages: 1582
Registered: January 2014

Senior Member

Thanks for pointing this out. These are definitely things we would like to have fixed.

The problem I see in the executeEvent is that it correctly masks out the client termination for servers. unfortunately also the server termination itself. I think it would be much nicer to have a dedicated function handling init and one for the rest. Then the code would be clearer and easier to get correct. What do you think?

Report message to a moderator

Re: Server disconection [message #1757888 is a reply to message #1757866]

Tue, 21 March 2017 10:44

Adrian Orive

Messages: 38
Registered: March 2017

Member

Alois Zoitl wrote on Mon, 20 March 2017 21:28

The problem I see in the executeEvent is that it correctly masks out the client termination for servers. unfortunately also the server termination itself. I think it would be much nicer to have a dedicated function handling init and one for the rest. Then the code would be clearer and easier to get correct. What do you think?

From a programming point of view, both dedicated functions and a switch case structure seem right to me. After all, you will probably have to call these dedicated functions from inside a switch case structure inside the executeEvent. It could make the code a bit cleaner.

I still think that these two errors (server and client termination for Server FBs) should not have the same return code, thus avoiding this kind of problems.

Report message to a moderator

Previous Topic:	FORTE: the initial size of the event chain's external event list.
Next Topic:	FBTester

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 11:12:15 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter