From f96hajo at chalmers.se  Fri Jan 17 15:50:48 2025
From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=)
Date: Fri, 17 Jan 2025 15:50:48 +0100
Subject: [subexp-daq] lwrocmerge stream server problem coupled with Go4
In-Reply-To: <7dfa028705204952ad36f4fc2c4ccbef@gsi.de>
References: <7dfa028705204952ad36f4fc2c4ccbef@gsi.de>
Message-ID: <2803af46-edf2-91a7-4322-9a6c7387e6c1@chalmers.se>


Dear Martin,

Does it work to connect the go4 to a transport server?

(The protocols are very similar, the only on-wire difference is actually 
that a stream server sends back a request to get a new block of data every 
time.  but drasi does not care about that, it just sends data anyhow, and 
eats whatever garbage (request) the consumer is sending to it).

Both transport and stream protocols start by sendsing a 16-byte 'info' 
header to the client.  This I have abused a bit to send some additional 
information about port mapping.  This may actually be only in the stream 
case and not in the transport case, since there the data transmission 
starts without any further request, such that I cannot play that trick.)

It may be that go4 does not like that abuse.  However, those port map 
tricks were first done in ucesb, so should be the same.  So that is a bit 
of a wonder then...

Other test: can you use a plain go4 ('empty' equivalent) and see if that 
is willing to eat the data from drasi?  If not, we have source so can 
debug...

Hmm, the drasi '--server' option has the 'forcemap' option, but that would 
surely not help.  One could implement a 'nomap' ('noportmap') option to 
turn these tricks off, if they turn out to be the issue.  That then leads 
to the fun with 'port-in-use', but that's another story...

What may then be nicer to use is (if transport protocol works) to just use 
a transport server, but on another port.  And tell that --server to be 
'nohold'.  That is then the equivalent of a transport server in that it 
does not hinder the DAQ if it does not keep up.

I'm Cc'ing the subexp-daq at lists.chalmers.se also, as this info may be 
useful for someone else.  (And also that this might be a point that could 
use better documentation...  A small protocol description...)

Cheers,
H?kan



On Fri, 17 Jan 2025, Bajzek, Martin wrote:

> 
> Dear Haakan,
> 
> 
> there's an issue if a Go4 client connects to a stream server from drasi
> timeorderer (lwrocmerge executable).
> 
> The client connects successfully but throws some error (can't debug with
> -ggdb3, as the build is not ours) on the very first event.
> 
> Says that something is wrong with the event source.
> 
> 
> However, if I spawn] a UCESB intermediary:
> 
> ./empty/empty stream://daq --server=stream
> 
> 
> Then everything works fine..
> 
> 
> Could this be that the LMD packets in lwrocmerge stream server are different
> than in the UCESB empty server?
> 
> If not, what would be the suspect?
> 
> 
> Cheers,
> 
> -- Martin
> 
> 
>