Subject: Re: SDL-News: Modeling message loss in SDL
From: Susanne Graf (Susanne.Graf#imag.fr)
Date: Thu May 29 2003 - 07:14:04 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Susanne Graf <Susanne.Graf#imag.fr> to sdlnews -----
It is certainly true that the way in which one could specify "channel
behaviours" in previous versions of SDL was not ideal; nevertheless, some kind
of "channel behaviour" definitions is exactly what is needed here. And to have
it as a distinct concept (which can be recognized by verification tools) rather
than just an ordinary process, is also important. It would be interesting to
think about reintroducing such a concept in SDL, which should be able to cope
with other than layered protocols.
-- Susanne GrafRick Reed TSE wrote: > Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm> > The originator of this message is responsible for its content. > -----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews ----- > > Cris Fuhrman at christopher.fuhrman#etsmtl.ca wrote on 28/05/2003 21:35: > > >>In SDL, is there a way to specify the behavior of a process that simply >>repeats a signal from one route to another? That is, whatever is received on >>route A is repeated on route B, without having to go into the details of the >>signal name and its possible parameters? I have seen the use of a CHOICE >>proposed in Laurent Doldi¹s book SDL Illustrated as a way to have an >>abstraction of a set of signals. This approach is surely better than treating >>each message, but it is still not completely generic and requires defining >>types for each message. One cannot easily reuse the ³network medium² block for >>other applications without redefining the CHOICE and the types. > > > Dear Cris, > > There is no shorthand way of doing what you want. > > You can use an INPUT * to consume any signal (not explicitly mentioned - > which is all signals if none are explicitly mentioned), but > > a) in this case the parameters are lost; > > b) there is no mechanism for finding out what signal was received. > > So the only possibility in SDL at present is to explicitly input each signal > by identity and storing the parameters (if any) in variables followed by an > output using the same identity obtaining the parameter values from > variables. > > The need to determine the identity of the signal type of the last signal > received and to be able to output this signal without modification has been > recognised for some time and proposals have been discussed by the language > expert group, but so far no feature has been agreed. > > So I think the best that can be done with SDL is as suggested by Laurent in > SDL Illustrated - collapse all the signals into one signal type with a > CHOICE data type to distinguish the different cases. The disadvantages of > this is that it is then not possible to save specific messages (except > internally in a process), and determining the actual message received from > the network medium will be a decision rather than an input. > > The ideal for a layered protocol would be at the upper layer to treat the > signals as distinct and at the lower layer to treat than all as one signal > type. Unfortunately SDL does not support this (at present). > > -- > Rick Reed - rickreed#tseng.co.uk > Tel:+44 15394 88462 Mob.:+44 7970 50 96 50 > > > > --End text from Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews --- > For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm> > For help, email "majordomo#sdl-forum.org" with the body of your email as: > help > or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org
--End text from Susanne Graf <Susanne.Graf#imag.fr> to sdlnews --- For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:49 GMT