Skip to main content
Home
for DLMS smart meters
Open source solutions for DLMS smart metering

Main navigation

  • Home
  • Products
  • About us
  • Open Source
  • Community
  • Forum
  • Downloads
User account menu
  • Log in

Breadcrumb

  1. Home
  2. Asynchronous Support In Gurux DLMS Stack (.NET)?

Asynchronous support in Gurux DLMS stack (.NET)?

By Christian247 , 13 February, 2026
Forums
Gurux.DLMS

Hello,

we intend to use the Gurux DLMS .NET stack for a system that needs to communicate with a large number of smart meters in parallel.

Our application architecture is fully asynchronous and uses async/await throughout the entire call chain. However, we have not found any indication that the Gurux DLMS stack supports asynchronous communication.

From what we can see, communication appears to be implemented using synchronous/blocking socket calls.

Our concern is the following:

We need to poll a high number of meters concurrently. So, if each TCP connection requires its own dedicated thread due to blocking I/O, this may lead to ThreadPool starvation under load.
We are also concerned about scalability limits if threads cannot be efficiently reused.
Ideally, we would like to avoid creating one thread per TCP connection.

Therefore, I would like to ask:

- Does the Gurux DLMS .NET stack support asynchronous socket communication internally?

- If not, is there a recommended pattern for integrating it into a fully async application?

- Is it possible to use the stack in a non-blocking manner without allocating a dedicated thread per TCP connection?

Our goal is to scale communication to a large number of meters without running into thread exhaustion or unnecessary blocking.

Any help on recommended architecture or best practices would be highly appreciated.

Thank you in advance.

Christian

Profile picture for user Kurumi

Kurumi

2 months 1 week ago

Hi, Gurux DLMS only…

Hi,

Gurux DLMS only generates and parses the bytes; you can send bytes to the meter as you wish.

There are multiple parameters that must be stored. So each thread must have own instance from the DLMS client, and you must keep this instance until you close the connection. Without this there are no limitations with sync or async communication.

BR,
Mikko

  • Create new account
  • Reset your password

Hire Us!

Latest Releases

  • Tue, 06/09/2026 - 11:16
    gurux.dlms.java 4.0.95
  • Tue, 06/09/2026 - 10:03
    Gurux.DLMS.Python 1.0.199
  • Mon, 06/08/2026 - 13:39
    gurux.dlms.cpp 9.0.2606.0801
  • Mon, 06/01/2026 - 10:15
    gurux.dlms.cpp 9.0.2606.0101
  • Thu, 05/28/2026 - 16:06
    gurux.dlms.java 4.0.94

New forum topics

  • Error reading L&G Meter
  • Pass a TCP Client to GXNet
  • Australian EDMI Mk10D (Essential Energy area)
  • Strange mix of data notificiation vs get response
  • DLMS Connection
More
RSS feed
Privacy FAQ GXDN Issues Contact
Follow Gurux on Twitter Follow Gurux on Linkedin