Closed mohantyytasre closed 8 months ago
The AE validation is not done on the client side, but on the server side. The client is the one who is initiating the whole association, so it is assumed that the client actually wants to communicate. The server on the other hand receives many association and is the one to validate and decide if the association should be accepted or not.
So the client builds up the AssocationRequest message, which already contains the clients AETitle and the AETitle of the server to which the client wants to talk. Then on the server side in method OnReceiveAssocationRequestAsync the server then receives the AssociationRequest message, checks if the server feels responsible for the called AETitle and if the server allows the client with the calling AETitle to open the association. Depending on that, the server accepts or rejects.
The idea of the AETitle is not validation, this would be way too unsecure and easy to "hack", its rather about configuration. If the client connects to a port and requests an association to a server with aet STORESCP, then the server may forward this request to a storage service, and if the request is for a server aet QUERYSCP, then the server forwards it to an other internal process. And if a worklist-server receives an association request of a client with aet MRT_SCU then the worklist server may return only the mri-data, but if the request comes from a client with aet CT_SCU, then the ct-data is returned.
if you want to write a server that checks the AETitles on AssociationRequest, then you have to write your own. Or you could create a class inheriting from DicomCEchoProvider
and override the virtual method OnReceiveAssociationRequestAsync. Like so:
public class MyCEchoProvider : DicomCEchoProvider
{
public MyCEchoProvider(INetworkStream stream, Encoding fallbackEncoding, ILogger log, DicomServiceDependencies dependencies) : base(stream, fallbackEncoding, log, dependencies)
{
}
public override Task OnReceiveAssociationRequestAsync(DicomAssociation association)
{
// first check the aetitle
if (association.CalledAE != "AAA")
{
return SendAssociationRejectAsync(DicomRejectResult.Permanent, DicomRejectSource.ServiceProviderPresentation, DicomRejectReason.CalledAENotRecognized);
}
// else just handle the c-echo requests as in base class
return base.OnReceiveAssociationRequestAsync(association);
}
}
and build up your server with
// Set up SCP (Service Class Provider)
var dicomserver = DicomServerFactory.Create<MyCEchoProvider>(port, null);
OK got it...Thanks for explaining in simplified way in this complex world of DICOM :)
As the Association gets terminated at the end of each request can I ask a basic question: To send multiple requests like C-Echo and C-STORE requests from client to server is it possible in single Association what changes i code can help me to do so or for each request do client and server need to associate separately.
Sure, you can call await client.AddRequestAsync(...);
several times with various requests before calling await client.SenAsync(...)
I am implementing Print SCU and Print SCP from Samples/Desktop. I am facing issues for it as
--> Print SCU : want logs for each N-Event Request (N-Create, N-Set, N-Action) . I have logged the events for association but is not able to get log using dicomClient.OnNEventReportRequest .
--> Print SCP : in the following code in PrintJob.cs
private void OnPrintPage(object sender, PrintPageEventArgs e)
{
_currentFilmBox.Print(e.Graphics, e.MarginBounds, 100);
_currentFilmBox = null;
_currentPage++;
e.HasMorePages = _currentPage < FilmBoxFolderList.Count;
}
_currentFilmBox is of type FilmBox and not have the .Print method rather it has .PrintStandard and such methods. So it is giving error on it.
Please help me to resolve this to complete this implementation.
fo-dicom.core is completely platform independent. Printing and graphics still has some platform dependencies in .net. It relates to GDI and therefore only works on windows. The Print method here on FilmBox instance is an extension method. You have to add a nuget reference to fo-dicom.Imaging.Destkop. There in the namespce FellowOakDicom.Printing this method is included.
... but this now is off topic of this issue. To I will close this issue for now. If there is still some issue related to AETitle on Server, please feel free to reopen this issue.
Expected behavior
I am new to DICOM and using fo-dicom library for DICOM communication. I have used the following code to simulate DICOM Client and DICOM Server on separate systems to test DICOM Asssociation and send DicomCEchoRequest. If I set some other AE Title on Server system the association should get rejected .
namespace DicomClient { internal class Program { static FellowOakDicom.Network.Client.DicomClient Client;
}
namespace DicomServer { internal class Program { const int port = 8000; static DicomServer Server;
}
--> Client should validate the Server AE Tiltle.
Actual behavior
--> For any Server AE Title in
Client = CreateDicomClient(IPv4Any, port, "SCU", "SCP"); the association is getting established.
--> Client is not validating the Server AE Tiltle. -->For Client am I setting Client AE Title correctly or not? --> Not clear for how to set the Server AE Title. --> The association is getting terminated immediately.
Steps to reproduce the behavior
Run the code
fo-dicom version and OS/platform
5.1.1 and Windows 10