Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Server disconection(Unexpected silent server disconection behaviour)
Server disconection [message #1757827] Mon, 20 March 2017 11:54 Go to next message
Adrian Orive is currently offline Adrian OriveFriend
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.
Re: Server disconection [message #1757849 is a reply to message #1757827] Mon, 20 March 2017 15:22 Go to previous messageGo to next message
Adrian Orive is currently offline Adrian OriveFriend
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.
Re: Server disconection [message #1757866 is a reply to message #1757849] Mon, 20 March 2017 21:28 Go to previous messageGo to next message
Alois Zoitl is currently offline Alois ZoitlFriend
Messages: 645
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?
Re: Server disconection [message #1757888 is a reply to message #1757866] Tue, 21 March 2017 10:44 Go to previous message
Adrian Orive is currently offline Adrian OriveFriend
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.
Previous Topic:FORTE: Bug in CIPComLayer
Next Topic:FBTester
Goto Forum:
  


Current Time: Sun Oct 21 01:56:55 GMT 2018

Powered by FUDForum. Page generated in 0.02232 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top