1239   Entry ID

Created: 13 Apr 2014

Status: Not Applicable

Part: Part 7-2 (2010; Edition 2)

Links:

Page: 84

Clause: 14.2.2.15

Paragraph:

Category: Issue for edition 2 of this part

Issue

In a situation where the RCB's packets are discarded due to port congestion at the client side, whether the same will be known to the server? As the client is not giving any return receipt of the Entry ID it has received.

More explanations are to be provided how the Server recognizes the loss of packets.


This allows a client to set the EntryID to the last value of the EntryID received with the last proper report
in order to synchronize with the server. Setting the EntryID may also be used to acknowledge the reception of
reports (or to resend reports)

Proposal

Whether the client writes the entry ID it Receives to the Server if so where it will be written and how the Server will manage to send the lost packets back to the client.

Discussion Created Status
14 Apr 14 Not Applicable
Agreed, the server does not verify receipt.

Suggest changing status to blue. 		14 Apr 14 Discussion (red)
14.2.2.15 ; P 84 is taken from IEC 61850-7-2 Edition one and therefore is not an edition 2 TISSUE.
Acknowledging each report is not a solution to solve the congestions at client.
Additonally, reporting is an unsolicited services.
TCP IP will take care of retransmitting not acknowledge packet.
The use of BufOvfl allows the server to inform the client that a resynchronization is needed (e.g. if the congestion at the client is so bad that it impacts the sending socket at the server). An abort can also be used in order to properly recover of the congestion.
The client is responsible for resynchornization, and therewith writes the EntryID he would like the server to start after.
The recognation at the server side depends on the implementation (socket error call) and is therefore not a standardization issue.
14 Apr 14 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 25.2.18.2