Re: stream/asyn devices

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Emmanuel,

Emmanuel Mayssat wrote:
> Update on stream device records
>
> Stream records are actually quite simple to implement.
> I found what appears to be bugs in the implementation, but some could
> describe those as features. Mainly the entire part of the afternoon was
> spend on trying to find out how the terminator is matched.
>
> Although terminator appears to be of unlimited length in stream, it
> seems that asyn impose its 2 chars limits for eos. As a result the
> stream terminator consist of the last 2 char of its value.

StreamDevice works around this limitation of asyn. But that requires 
that asyn allows to read the input in multiple parts. Actually, stream 
gives the last one or two characters of the terminator (as much as the 
underlying asyn port driver accepts) to asynOctett. When asynOctett 
thinks it has found a terminator, StreamDevice checks if the full 
terminator matches. If not, it restores whatever terminator part asyn 
had cut off and tries to read more.

> Stream device can actually handle http connection (not permanent
> connection) with the "disconnect" protocol option. That was a good
> surprise.

I never tried to read http with StreamDevice so far. I am not sure if 
the http server closes the connection automatically. But you're right, 
you can include manual connect/disconnect into the protocol. I found 
that asyn's auto-connect does not always work as expected. I had 
situations where access to a disconencted port failed even though asyn 
did auto-connect only the second access succeeded. Thus, it is probably 
better to do an explicite conenct first.

> The matching works well (once the terminator issue was handled), but I
> would have loved traditional regex matching. Matching a complex/long
> reply like a web page seems tedious.

Yes. That's still missing. Regexp matching is a rather complex issue. I 
just did not find the time to implement it. But the good news is that 
you can add new % formats by writing a C++ class for it. Look how it is 
done in the *Converter.cc files. I think I will use a format like 
%/regexp/ once I find the time to do it.

> But overall, I have been impressed by this record and would encourage
> all of you to have a closer look at stream. BTW, I use stream from the
> synApps-5.2 package.

The latest version is always available at 
http://epics.web.psi.ch/software/streamdevice/. I don't know and have no 
control over the version in synApps.

StreamDevice is not the new devGpib. It just uses the same lower level 
driver, asyn. Thus, it is an alternative to devGpib. The real new 
devGpib which has the same API as the old one is included in asyn. 
Actually, I have written StreamDevice to have a more flexible API which 
is easier to use (e.g. no compilation)

Best regards,
Dirk

> --
> Emmanuel Mayssat
>
>
> On Thu, 2007-07-26 at 14:59 -0700, Emmanuel Mayssat wrote:
> > Hello again,
> >
> > I have a device which has a web server and a simple web page.
> > My record should fetch the web page and extract the value between the
> > <epics> and </epics> tags. Can asyn do that? ( it probably can ;)
> >
> > Better yet, I looked at the streamDriver which is also said to work on
> > TCP/IP. Can stream records do that?
> > One could argue that the TCP/IP connection is not permanent (i.e the
> > server kicks you out if the client is idle, but asyn should
> > auto-reconnect right?)
> >
> > http://epics.web.psi.ch/software/streamdevice/doc/
> >
> > Also is stream the new devGpib ?
> >
> > --
> > Emmanuel