I am trying to troubleshoot some ongoing network issues with a customer that causes agents to disconnect
from time to time.
Is it normal that dataminer would from time to time try to send information that far exceed the capacity of even a Jumbo Frame packet?
Are Jumbo Frames allowed/tested in dataminer?
In my setup, I am seeing .net remoting POST messaged that are enormous at 89766 Bytes: 
Is there a way to have DataMiner make smaller payloads in these HTTP post messages?
I think these large packets are completely normal, TCP port 8004 is used for .NET Remoting which carries client-server & inter-dataminer traffic. As you noticed, this is actually done via HTTP POST requests, which can be quite large (even though they are compressed and encrypted). Large HTTP requests are split up into multiple packets.
If you think the issues are network load related, I would recommend to monitor the NICs on the DataMiner agents to see if they are not at maximum capacity. Other than this it would be good to check the SLNet & SLDMS logging for connection issues.
Another thing that could be worth checking is the NIC configuration (Nic-teaming options, failover across physical interfaces, active/active and so on)
Indeed Alberto! Maybe just another note, when .NET Remoting will be replaced by gRPC the traffic can start using HTTP 2 (now we’re still depending on HTTP 1.1), which should be much faster & better at handling large requests/responses.
Out of curiosity – as I don’t think it would impact server-to-server connections in the cluster, but – on the client-server side, would there be any different amount of traffic through port 8004 when comparing client connection modes, i.e. polling VS eventing?
I think this particular issue may be exposed because the connections between agents in the cluster that are located in separate security zones are federated through enterprise firewalls for security and these firewalls are likely using deep packet inspection. So it’s perhaps not network load related, but network through-put related due to firewall processing constraints.
Alberto, I wasn’t sure so I did a small test, one using eventing, one using polling on the same system and opening the same element for 1 minute. Using eventing I saw 2.253.219 bytes, using polling I saw 1.938.555 bytes, so it looks like eventing consumes slightly more bandwith (on my system). I think the biggest factor here will be the polling interval, the higher the frequency of pollin the more will data will be consumed.
Ref. Jumbo frames, recently came across this being tested for specific protocols, so for the acquisition interface – but haven’t faced it through port 8004. Is the DMA using the same interface for both corporate/client connection & data acquisition?
Subscribing to get more insights from the community.