Exception for payload mismatch - bug or feature?

[varenius]

Playing around, I decided to set the recording mode to expect VDIF packets with 8192 bytes payload (8224 total size) but instead fire packets with payload size 8000 bytes (8032 total size). I got:

202124206:48:34 2021-08-30 04:48:34.56: Processing command 'mode?'
202124206:48:34 2021-08-30 04:48:34.56: Reply: !mode? 0 : VDIF_8192-8192-64-2 : VDIF : 128 : 64000000.000 : 8192 ;
202124206:48:37 2021-08-30 04:48:37.55: Processing command 'version?'
202124206:48:37 2021-08-30 04:48:37.55: Reply: !version?  0 :  jive5ab : 3.1.0 : 64bit : Debug : skirner : 20-Mar-2021 : 12h11m58s : nossapi :  ;
202124206:48:37 2021-08-30 04:48:37.55: Processing command 'rtime?'
202124206:48:37 2021-08-30 04:48:37.55: Reply: !rtime? 0 : 34256.4s : 35215.6GB : 9.03097% : VDIF : 128 : 0MHz : 8224Mbps ;
202124206:48:37 2021-08-30 04:48:37.55: Processing command 'datastream?'
202124206:48:37 2021-08-30 04:48:37.55: Reply: !datastream? 0 : 1 : {thread} ;
202124206:48:37 2021-08-30 04:48:37.55: Processing command 'mode?'
202124206:48:37 2021-08-30 04:48:37.55: Reply: !mode? 0 : VDIF_8192-8192-64-2 : VDIF : 128 : 64000000.000 : 8192 ;
202124206:48:37 2021-08-30 04:48:37.55: Processing command 'tstat='
202124206:48:37 2021-08-30 04:48:37.55: Reply: !tstat= 0 : 0.0 : no_transfer ;
202124206:48:37 2021-08-30 04:48:37.55: Processing command 'record=on:testrec_freja_210830_044837'
202124206:48:38 2021-08-30 04:48:38.31: close_filedescriptor: closed fd#10
202124206:48:38 2021-08-30 04:48:38.31: getsok: req. server socket@udpsnor:26411
202124206:48:38 2021-08-30 04:48:38.31: Reply: !record=  0  ;
202124206:48:38 2021-08-30 04:48:38.31: Processing command 'tstat='
202124206:48:38 2021-08-30 04:48:38.31: Reply: !tstat=  0 : 1630298918.318 : vbsrecord : FIFOLength : 0;
202124206:48:38 2021-08-30 04:48:38.31: udpsnorreader_stream: fd=10 data:8224 total:8232 pkts:32640 avbs: 1
202124206:48:38 2021-08-30 04:48:38.31: udpsnorreader_stream: not allowed to push variable block of size 0 bytes for stream 4 (lost)
202124206:48:38 OH NOES! A step threw an exception:
202124206:48:38 **** ::recvmsg(network->fd, &msg, /*flags*/) fails - [] (ask:24 or 8232 got:8040)
202124206:48:38 2021-08-30 04:48:38.31: net2vbs guard function: transfer done
202124206:48:39 2021-08-30 04:48:39.31: Processing command 'tstat='
202124206:48:39 2021-08-30 04:48:39.31: Reply: !tstat= 0 : 0.0 : no_transfer ;
202124206:48:40 2021-08-30 04:48:40.32: Processing command 'tstat='
202124206:48:40 2021-08-30 04:48:40.32: Reply: !tstat= 0 : 0.0 : no_transfer ;
202124206:48:48 2021-08-30 04:48:48.32: Processing command 'record=off'
202124206:48:48 2021-08-30 04:48:48.32: Reply: !record=  6 : Not doing record ;

I was surprised by this, because I had a vague memory that jive5ab would adapt to whatever is being trown at it, regardless of the setting. But, indeed it seems it refuses to record the "wrong" format. This is fine with me, but I just wanted to check if this is a bug or feature?

[haavee]

Hi Eskil, your memory is too vague, unfortunately. This has been a feature, dating from the earliest e-VLBI transmissions. Others have "complained" about this before, but so far, to not let such an error go by silently, has proven to be a good diagnostic. The system is already very complex and "silent errors" are a topic that requires continuous evaluation: when & where to allow. I think that ultimately the vdif framesize should be driven by what's configured in the VEX2 $DATASTREAMS block; there the data format is defined what the user expects the system to deliver. Where possible, the subsystems should try to verify that it is indeed providing what's expected. (But of course this is subject to negotiation by all parties involved ...)

[varenius]

Personally I like the error, I was just surprised :). Good to learn it was my memory that was "wrong" in this case. I think we can let this rest.