Send EVIO events through TCP

[DraTeots]

We should be able to use jana4ml4fpga to send EVIO events over TCP emulating real hardware (to some degree. Initially just send it).

This is required for working on FPGA software using real data saved in JLab and Fermilab testbeams

[cissieAB]

Write down some notes for discussion.

Referred codes

CDaqEventSource.cc

Receive data from TCP (and save it to *.evio file optionally)

• Line 184: receive 10-word header
• Line 247: receive 3-word header
• Line 337: receive real data
• Line 342: Process the data to pack it into an EVIOBlockedEvent object block:
  • Add 2 words before real data
  • Swap real data
  • Parse the whole block (2 added words and swapped real data) into JEvents object.

EVIOBlockedEventParser.cc

Parse each EVIOBlockedEvent object block into JEvents object.

• Line 91: write an entire block to an output file

EVIOFileWriter.h

• Line 65: write each chunk of data to output file. Every time add an 8-word header before it.
• Line 38: write an 8-word tail to output file upon close.

CDAQEVIOFileSource.cc

Every call to m_hdevio->readNoFileBuff() generates one EVIOBlockedEvent object block.

tcp_sender.cc

A stand-alone executable to send data via TCP. Don't know where its data come from.

Some initial thoughts

• When reading an *.evio file with m_hdevio->readNoFileBuff() and getting 1 block of data, the first 2 words of the block need to be removed, and the remainder need to be swapped, before sent via TCP.
• Should the process follow tcp_sender.cc (search for tcp_event_snd appearances)? Or, reverse CDaqEventSource.cc instead?
• Why 8-word header in EVIOFileWriter.h and 3-word header in tcp_sender.cc?

[faustus123]

A few more notes:

• There are multiple attempts at adding the TCP functionality

1. executables/original_tcp_tester looks to be Sergey's original code that is independent of JANA. Ignore this since the important parts were copied elsewhere
2. executables/tcp_daq_tester is also a pair of JANA-independent program s, but that use the libraries/tcp_daq library. These generate minimal, fake evio blocks for sending data for the purposes of testing.
3. libraries/tcp_daq is a library that contains the C code from executables/original_tcp_tester in a form that can be used by other parts of the code. I gather it was put here for the purpose of integrating into a JANA library or plugin, and then tested for functionality with the executables/tcp_daq_tester programs.
4. plugins/CDAQfile doesn't have anything to do with the TCP functionality, but is does implement a JANA event source that uses libraries/rawdataparser to parse the data read from a file. It may serve as a useful example of using the parser library for data read from a TCP socket.
5. plugins/cdaq is a plugin that implements a JEventSource for reading events from a CDAQ source via TCP.
6. plugins/deprecated_CDAQtcp as the name implies, is deprecated code. It looks to have had minimal work at the time it was abandoned so does not provide a useful example at this point compared to the other code.

plugins/cdaq is the place where it looks like the work was left off. It implements a JEventSource that receives data via tcp, and also has at least one place where it tries to send data (L217 in CDAQEventSource.cc). It has a lot of TCP code it it rather than using [libraries/tcp_daq(../blob/main/src/libraries/tcp_daq).

Here are the items that should be done:

1. The CDaqEventSource class in plugins/cdaq should be modified to use libraries/tcp_daq
2. Once read in from TCP, the CDAQ event buffer should be placed inside an object that is written to a factory as a JANA object. This object will need to be a new class that keeps a shared pointer to the buffer as well as any metadata such as buffer length.
3. A CDaqEventTCPSender class should be added to the cdaq plugin that inherits from JEventProcessor. It should pull the event buffer from JANA using the standard mechanism and send it using the tcp_daq library
4. Special care may be needed for BOR events, but that should be deferred until later.

[faustus123]

This is now complete with PR #51 and PR #53. It only mimics sending fully built events through, but that should be sufficient for the ongoing test series.