Posts by SM1312

Thanks for the confirmation marcelvanherk

I have increased the timeout for TCPIPTimeOut to 600 (in "dicom.ini") and the error seems to have solved by this.

Will this increase in timeout have any signifcant performance issues with Conquest or any other likely issues?

Thanks.

Hi marcelvanherk

I am using Conquest v1.5.0c webserver but with the exe of v1.5.0e.

In the PHP code, I have a custom code to export data from CQ to destinations

function moveCmd ($pt, $st=null, $se=null) {
  try {
    include 'config.php';
    $t = parse_url($_SERVER["REQUEST_URI"]);
    $level = '';
    $UIDs = '';
    //check if a 'query' is present in the URL, otherwise drop it
    if (array_key_exists("query", $t)){
      /* based on the non-null UIDs supplied, work out at what level the 
      command must be executed, and concatenate the UID arguments */
      if($se != null){
        $level = 'series';
        $UIDs = $pt.':'.$se.','.$st;
      }
      elseif($st != null){      
        $level = 'study';
        $UIDs = $pt.':'.$st;
      }else{      
        $level = 'patient';
        $UIDs = $pt;
      }
      //form the actual servertask command
      $op = ' --move'.$level.':';
      //parse the query for extracting the list of destination AE titles
      $output = array();
      parse_str($t["query"], $output);
      
      $srcAE = array_key_exists("srcAE", $output) ? $output["srcAE"] : null;
      if(is_null($srcAE) || empty($srcAE)){
        //retrieve the name of our source Conquest server; 
        $localAE = exec($exe.' "--get_ini_param:MyACRNema');
        //remove the bloody null bytes, in order to work (gave us a headache)
        $srcAE = str_replace(chr(0), '', $localAE);
      }
      $failedDest = array();
      foreach($output['dstAE'] as $AE){
        //concatenate the source and destination AEs
        $AEs = $srcAE.','.$AE.',';
        //put together the whole command string
        $cmd = $exe.$op.$AEs.$UIDs;
        //execute the server command
        $res = exec($cmd);
        // Remove anything other than printable ASCII from the result
        $res_pruned = preg_replace('/[^\x20-\x7E]/', '', $res);
        // If '0' is not returned, then the move cmd was unsuccessful
        if ($res_pruned !== '0'){
          array_push($failedDest, array(
            'destination' => $AE,
            'error' => $res_pruned,
          ));
        }
      }
      if ($failedDest){
        echo json_encode(array(
          'isError' => true,
          'result' => $failedDest
        ));
      } else{
        echo json_encode(array(
          'isError' => false,
          'result' => 'success',
        ));
      }
    } else{
      throw new RuntimeException('No destination AE Titles specified');
    }
  } catch (Exception $e){
    echo json_encode(array(
        'isError' => true,
        'result' => $e->getMessage()
    ));
  }
}

In the php.ini, I have the max_execution_time=480 (8 mins) to accomodate slow exports. Exporting to Elekta's Mosaiq is always slow and I don't know why.

But the real issue is with such slow exports, I get an error from the PHP like this
[{"destination":"DEST_NAME","error":"DICOM ERROR Protocol error 0 in PDU:Read"}

In debug mode, sometimes in CQ's serverstatus log, I see this warning ReadAheadThread: warning - resolving deadlock due to erratic incoming order but no error.

But the strange thing is all the data gets sent to the destination properly despite being slow and webserver returning error.

Does CQ's application code has any default timeout for exports or something aside from the PHP settings?
I don't know why this error is reported by the webserver and completely unsure how to debug or solve this?

Any help would be appreciated? Thank you.

marcelvanherk,

Thank you. I have got it to work with the below:

        const formData = new FormData();
        
        formData.append('script', 'Data:AddImage();return(1)');

        const fileBuffer = await fs.readFile(fpath);
        const fileName = path.basename(fpath);
        const blob = new Blob([fileBuffer], { type: 'application/dicom' });
        formData.append('dcmfile', blob, fileName);

        try {
            const response = await fetch(url, {
                method: 'POST',
                body: formData,
            });

            if (!response.ok) {
                throw new Error(`Failed to POST: ${response.status} ${response.statusText}`);
            }

            const responseBuffer = await response.arrayBuffer();
            return Buffer.from(responseBuffer);
        } catch (err) {
            throw err;
        }

Hi marcelvanherk

Sorry forgot to add the error message. here it is:

<b>Warning</b>:  Undefined array key 0 in <b>F:\Program Files\xampp\htdocs\api\dicom\posters.php</b> on line <b>135</b><br />
<br />
<b>Warning</b>:  Trying to access array offset on value of type null in <b>F:\Program Files\xampp\htdocs\api\dicom\posters.php</b> on line <b>138</b><br />
<br />
<b>Warning</b>:  Trying to access array offset on value of type null in <b>F:\Program Files\xampp\htdocs\api\dicom\posters.php</b> on line <b>138</b><br />
*** lua run error posters.lua:4: bad argument #1 to 'write' (string expected, got nil) in 'dofile([[posters.lua]]);attachdicomfile([[C:\Users\username\AppData\Local\Temp\php3981.tmp]], [[]])'

Hi marcelvanherk

I am trying to use the webserver API to attach a new DICOM instance/file (/rs/attachdicom) into the server.

In Nodejs, I have the below function (DICOM to be attached is read as a Buffer and sent)

 return new Promise((resolve, reject) => {
    const boundary = crypto.randomBytes(32).toString('hex').slice(0, 32);

    // Build the request body
    const firstLine = `--${boundary}\r\n`;
    const firstHdr = `Content-Disposition: form-data; name="dcmfile"; filename=${fname}\r\n`;
    const scndHdr = `Content-Type: application/dicom\r\n\r\n`;
    const endLine = `\r\n--${boundary}--\r\n\r\n`;

    const beginBlock = Buffer.from(firstLine + firstHdr + scndHdr);
    const endBlock = Buffer.from(endLine);

    let postData: Buffer = Buffer.concat([beginBlock, data, endBlock]);

    const options = {
        hostname: this.server,
        port: this.port,
        path: resourcePath,
        method: 'POST',
        headers: {
            Accept: 'application/dicom+json',
            'Content-Type': `multipart/related; type="application/dicom"; boundary=${boundary}`,
            'Content-Transfer-Encoding': 'binary',
            'Content-Length': postData.length,
        },
    };

    const req = http.request(options, (res: any) => {
        let data: any[] = [];

        res.on('data', (chunk: any) => {
            data.push(chunk);
        });
        res.on('end', () => {
            resolve(Buffer.concat(data));
        });
    });

    req.on('error', (err: any) => {
        reject(err);
    });

    // Write data to request body
    req.write(postData);
    req.end();
});

I couldn't get the request to attach dicom to be fulfilled as there is always some parsing issue with multipart content in attchdiomfile() function in posters.php].

Temporarily I got it work using my own functions:

function fpoststow() {
  include 'config.php';
  $currentDirectory = getcwd();
  $uploadDirectory = "\\uploads\\";

  $fileName = $_FILES['dcmfile']['name'];
  $fileSize = $_FILES['dcmfile']['size'];
  $fnameBits = explode('.', $fileName);
  $fileTmpName = $_FILES['dcmfile']['tmp_name'];
  $fileExtension = strtolower(end($fnameBits));

  if (!in_array($fileExtension,['dcm','dic'])) {
    $var = 'This file extension is not allowed. Please upload a Dicom file.';
  }else{
    $uploadPath = $currentDirectory . $uploadDirectory . basename($fileName);
    $didUpload = move_uploaded_file($fileTmpName, $uploadPath);
    if ($didUpload) {
      ob_start();
      passthru($exe . ' "--dolua:dofile([[posters.lua]]);fpoststow([['.$uploadPath.']])"');
      $var = $var . ob_get_contents();
      ob_end_clean();
      // now delete the file
      unlink($uploadPath);
    } else {
      switch($_FILES["dcmfile"]["error"]){
        case 1: $var = 'The uploaded file exceeds the upload_max_filesize directive in php.ini.'; break;
        case 2: $var = 'The uploaded file exceeds the MAX_FILE_SIZE directive that was specified in the HTML form.'; break;
        case 3: $var = 'The uploaded file was only partially uploaded.'; break;
        case 4: $var = 'No file was uploaded.'; break;
        case 6: $var = 'Missing a temporary folder.'; break;
        case 7: $var = 'Failed to write file to disk.'; break;
        case 8: $var = 'A PHP extension stopped the file upload.'; break;
        default: $var = 'Unknown upload error.'; break;
      }
    }
  }
  header('Access-Control-Allow-Origin: *');
  header('Content-Type: application/json');
  echo $var;
}

function fpoststow(path)
  local s = servercommand([[addimagefile:]]..path);
  iowrite(s or '')
end

Although my functions work, I would like to utilize the attachdicomfile function which you already provided.
But I couldn't figure out what's wrong with the parsing of the multipart content!!!

Am I doing anything wrong in building the request object for the POST request from Nodejs?

Any help would be appreciated! Thank you.

marcelvanherk Thank you. Both bugs are fixed.

Hi marcelvanherk

I have noticed few minor bugs in the webserver part of v1.5.0e (tested in Windows env).

1) For move commands, index.php (line 237) passes null as default for source AE. But this in rquery.lua (line 157) its treated as an empty string because of the parsing in qido.php (line 158).

Since its an empty string, local from = from or servercommand('get_param:MyACRNema')

from is always an empty string because of which dicommove throws the error "AE not found".

2) In rquery.lua, in some places, the output of the server command is passed directly to iowrite: iowrite(servercommand('lua:'..remotecode)).

But this causes nil error in iowrite function when there is no command output.

I have corrected them locally. Just listing them here, so you can add them to your next patch.

Thank you.

Hi marcelvanherk

Sorry for the late response. It did work. I just replaced libmysql64.dll with the one from MySQL8.4 lib folder - libmysql.dll.

Now, the Conquest is able to use caching_sha2_password authentication method instead of mysql_native_password.
Thanks.

Hi marcelvanherk,

Good afternoon. I am changing my existing Conquest installations to connect with MySQL Community Server 8.4.4.

In MySQL 8.0, mysql_native_password is being disabled and from 9.0, its being removed completely in favour of caching_sha2_password.

This being the case, Conquest can only connect with MySQL Server if its mysql_native_password

How to make it work with caching_sha2_password?

Any help would be appreciated. Thanks

Hi marcelvanherk

Yes. Basically, I already have the whole content of the dicom file as binary string. I just don't want to use filepath.

marcelvanherk

In webserver/htdocs/api.dicom/posters.lua, there is already a function poststow(path) which takes filepath.
I would like to add another similar function but instead of a filepath, it would take the binary dicom file content as argument.

I could try this myself but I am not sure how to structure those remotecodes for such a function?
If its not a bother, it would be very helpful if you could add such a function to the webserver.

Thank you.

Hi marcelvanherk,

Currently, I can upload a new DICOM file either using web api or by calling dgate directly by providing the filepath.

Is it possible to do the upload by passing the content (binary or buffer etc.,) directly instead of a filepath?

Thanks.

Hi marcelvanherk

I am currently using v1.5.0c on Windows.

Can I just update my dgate64.exe & ConquestDICOMServer.exe from v1.5.0e but retain the webserver from v1.5.0c?
Would it cause any issues?

Thanks.

marcelvanherk Awesome. Thank you. Could I please ask when are you planning to release this update?

Hi marcelvanherk

Conquest Version: 1.5.0d

When querying metadata, there is a minor incompatibility if the result is converted to JSON.

The reason being the Value Representation for DS allows optional + at the start of either a fixed point number or a floating point number.

Most of the programming languages don't care about the + at the front of a number but JSON treats it invalid.

If metadata result has to be converted into a valid JSON, its quite tedious in JS or similar languages. But its quite simple in the C++ source code.

I believe the issue can be rectified in the source Conquest-DICOM-Server/src/dgate/src/dgate.cpp

by just adding this if (*q == '+') q++; after Line 7847 (Please verify this!!!)

Would it possible to accommodate this change in a new minor release for [tt]dgate.exe[tt]?
Thank you for your consideration.

Thank you very much marcelvanherk. It works

Thank you marcelvanherk

marcelvanherk

Thank you.

But unfortunately, when I call servertask "--dolua:dofile([[rquery.lua]]);getmetadata(nil,[['.$st.']],[['.$se.']],[['.$sop.']])", the result is the same

I don't know why the result is 0.000000 whereas the Conquest headers show the full value .

marcelvanherk

When viewing the data (headers) in Conquest, I see the value without any problem.

The problem is only when I query the webserver of Conquest. I am not sure whether the issue is with lua or php code inside \webserver\htdocs\api\dicom.

I tried to call the specific getmetadata(...) function in rquery.lua from command line directly using dgate. But I believe the syntax is wrong and I can't get any result to debug this more.

dgate64.exe "--lua:dofile(\"./webserver/htdocs/api/dicom/rquery.lua getmetadata <AETITLE> <STUDYUID> <SERIESUID> <INSTANCEUID>\")"

Could you please look into this? Thank you.