Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Sun, 30 Oct 2005 13:56:08 +0100

On Wednesday 26 October 2005 00:33, Jeff Hill wrote:
> Attached is a rough cut at the EPICS V4 CA protocol specification.

Hi Jeff,

one more comment about a feature of the new protocol that makes me feel 
quite uneasy. This issue also provoked the first and longest remark in 
the Design Notes.

It may be that I haven't got the whole picture yet, but I think it is 
not acceptable to leave client applications in the dark about whether a 
channel connection request could be honored or not, for however short a 
time span. To qualify this as an "unfortunate drawback" doesn't quite 
capture it, AFAICS, and to say that "brief windows of uncertainty are 
not unreasonable" is, I think, wrong, if I may be so forward. This goes 
even /if/ you'd somehow manage to give strict timing guarantees for 
exception responses, which, AFAIK, are impossible to give, considering 
that ethernet-based networks are by construction not hard-real-time 
capable.

I wonder what clients are supposed to do after 'defining' a channel. 
Should they wait for NNN seconds after each such request, hoping they 
will be connected if they don't receive an exception until then? Or 
should they just start sending IO requests, hoping that the channel has 
connected?

Or, and this deems me as the most probable outcome, clients will 
routinely check that a channel has connected, namely by first issuing a 
suitable IO request (for instance a read) immediately after the channel 
connection request. If and when they receive a valid response, they 
know the channel is connected and only then start issuing the 'real' 
requests they want to send. Note that forcing clients to use such a 
'hack' will /increase/ network load instead of reducing it.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System