[evla-sw-discuss] VCI and Message IDs

[Bryan Butler]

the decision on whether to use UDP or TCP (or other) in the 
communications between the rest of the system and WIDAR has not been 
made, that i'm aware of.

you've pointed out you don't want to see UDP, kevin, but there are some 
real advantages - notably the simplicity (lack of overhead) and the 
availability of multicast (the latter is a significant capability 
missing in TCP or HTTP, IMHO).  UDP in closed networks is very reliable, 
from everything i've read, heard from james, and mostly in our 
experience within the rest of the M&C system (i believe we have had a 
few dropped packets over the entire time we've been running things, and 
most of those were tracked down to problems within the processes sending 
or receiving).

i'm not particularly fond of HTTP for everything because of the 
necessity for tomcat (or some other server), which in my experience has 
been a royal pain.

in any case, it's a decision to be discussed over the coming months.

	-bryan


Kevin Ryan wrote:
> Hello gang,
> 
> I would like to comment on Sonja's VCI document about the 'Message  
> ID' in which I disagree with its need or for its possible benefits  
> for 'debugging and troubleshooting'.  Its inclusion in the VCI  
> document suggests the use of UDP type communication between the EVLA  
> and WIDAR and I truly hope that is not the case.
> 
> And I also truly hope that the use of Message IDs does not penetrate  
> past the VCI.  WIDAR's internal communication infrastructure is based  
> on the fact that there will be no blind requests - every single  
> request _will_ be acknowledged.  Every request for a status or for a  
> configuration change will not be complete until the server has  
> acknowledged it (or the TCP or HTTP layers indicate a malfunction).
> 
> If the VCI-to-EVLA infrastructure maintains that philosophy, then the  
> two use-cases for Message-IDs in the VCI document become moot:
>   - "A VCI message generated as a direct reply to a received VCI  
> message should include the Message ID."
>     Since the request and response is a socket connection between the  
> requester and the responder, the response con only be for that  
> particular request.
> 
>   - "A log/alarm generated to report erroneous or unexpected message  
> or inability to act as specified ... should include [the] Message ID"
>     Any request that is 'erroneous or unexpected' will be immediately  
> known to the requester via the response.  If, later on, there is an  
> 'inability to act' then that is a different matter that has nothing  
> to do with the ID of original request and therefore does not need to  
> be linked to it.
> 
> Message IDs are a necessary complication for the implementor of UDP- 
> based communications but TCP/HTTP encapsulates that functionality so  
> we don't have to be bothered with it.
> 
> I therefore make two recommendations:
>   1) Remove the need for Message IDs (don't attempt a control system  
> based on communications 'in the blind'),
>   2) Remove Message IDs from the VCI document.
> 
> Regards,
> 
> Kevin
> 
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss