Enhancement #2770

Improve Participant creation

Added by S. Barut over 2 years ago. Updated over 2 years ago.

Status:ResolvedStart date:09/28/2018
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


To create the only implemented connection type by sockets, the BusClientConnection class uses the TcpClient class provided by .Net. By creating an instance with string, a dns service will be invoked to resolve an ip adress. This one seems to be really slow (really really slow, like 1-2 seconds). Thus the creation of a TcpClient is changed to directly using a byte array of size 4.
The caveat is, that only IPv4 adresses can be used now. The advantage is a fast participant creation.

This one will be further improved later, but a faster connection establishment now is really helpful.

0003-Improve-tcp-connection-establishment_685072f.patch Magnifier (2.2 KB) S. Barut, 09/28/2018 01:09 PM

0002-Improve-tcp-connection-establishment_531bea6.patch Magnifier (2.74 KB) S. Barut, 10/01/2018 02:12 PM

0001-Improve-tcp-connection-establishment_d138e5f.patch Magnifier (1.28 KB) S. Barut, 10/08/2018 01:43 PM

Associated revisions

Revision cc5776cd
Added by S. Barut over 2 years ago

Improve tcp connection establishment

Force IPv4 connections.

Somehow the .Net class TcpClient tries IPv6 until timeout using the
previous constructor initialization.

See also: https://stackoverflow.com/questions/18390715/why-is-the-tcpclient-slower-to-connect-with-parameters-in-the-constructor

fixes #2770

Signed-off-by: Johannes Wienke <>


#1 Updated by J. Wienke over 2 years ago

Eh, but host names should be supported. We need DNS resolution. No idea why this is slow on windows.

#2 Updated by S. Barut over 2 years ago

Sure, will be done. I see, I probably should only upload finished patches.. my bad. But I saw this one as really necassary, especially for RPCs...

#3 Updated by S. Barut over 2 years ago

The Connection will be established through an IPEndPoint object, which can be created outside, thus the user can use the same dns resolution for all connection instances.
For easier use, the user can still just give the ip address as byte array.

#4 Updated by J. Wienke over 2 years ago

But honestly, I don't see why resolving "localhost" is an issue. That should be close to instant. Once the external configuration system is added, that will also provide host names as strings.

#5 Updated by S. Barut over 2 years ago

I don't know, why .Net takes so long for that...

Internally, the Factory can resolve the configuration to an IPEndPoint. This one has at least all information a TcpClient in .Net needs, to create a connection immediatly. At least I hope so.

#6 Updated by J. Wienke over 2 years ago

Are you sure this is .net and not your system? Did you try resolving an IP in cmd?

#7 Updated by S. Barut over 2 years ago

I checked, it is not the system.
But i finally found a reason:
Funny, so actually the fix was a bit easier :)
But still, wouldn't it make more sense, if the host is just resolved one time and not in every participant creation?

#8 Updated by J. Wienke over 2 years ago

Who would be responsible for caching the results then?

#9 Updated by S. Barut over 2 years ago

I would say the one, who creates them. Most cases the Factory.

#10 Updated by S. Barut over 2 years ago

Well, more or less reverted everything but outsourced the connection of the TcpClient from the constructor (see SO-hyperlink)

#11 Updated by S. Barut over 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF