Cloud-Automation / node-modbus

Modbus TCP Client/Server implementation for Node.JS
471 stars 175 forks source link

dependency in time on localhost #110

Closed biancode closed 7 years ago

biancode commented 7 years ago

Dear Stefan,

Uncaught Exception:
Error: listen EACCES 0.0.0.0:502
    at Object.exports._errnoException (util.js:1022:11)
    at exports._exceptionWithHostPort (util.js:1045:20)
    at Server._listen2 (net.js:1249:19)
    at listen (net.js:1298:10)
    at doListening (net.js:1397:7)
    at _combinedTickCallback (internal/process/next_tick.js:77:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Since v2.0.x there is some dependency in time between the server and client on listening. It appears very often if the server has less then 100 ms (default is 10 ms) of response delay and the client is on a second interval.

With version 1.x that wasn't never a problem.

cya Klaus

psorowka commented 7 years ago

Klaus, can you elaborate that a bit? I didn't get the exact condition to reproduce this error..

biancode commented 7 years ago

Hi Peter, build a server as in the example from the readme file with the 10 or max 100 in responseDelay and build a client polling every second and both are on the same localhost. That should raise the error.

psorowka commented 7 years ago

hmm.. I wrote the following minimal sample.

Server:

let modbus = require('jsmodbus')
let server = modbus.server.tcp.complete({ port : 8888, responseDelay: 10 })

Client:

const modbus = require('jsmodbus')
const client = modbus.client.tcp.complete({
        'host'              : 'localhost',
        'port'              : 8888
})

client.connect()

client.on('connect', function () {
  setInterval( function () {
     client.readCoils(0, 13).then((r) => console.log(r.payload))
  }, 1000)
})

Ran that for a while (on Macbook Pro), didn't see any issues. Even reduced the numbers. Is that sample similar to what you are doing to produce the error?

Do you receive the error at the client or server side?

biancode commented 7 years ago

In my case it is running in Node-RED and in that case it will be started in two different instances of nodes. I'll try a little express app to check it again. If you've done that code in one file or in a synced piece of code that will work perfect every time, but what about async starting of both instances? Did you test it with randomize who is first to be active?

psorowka commented 7 years ago

I simply wrote two separate scripts and ran them from console.

I am still missing a couple of facts from your report:

I will later try to put my minimal sample into the same process which should model your case better

biancode commented 7 years ago

Hi Peter, thank you for your help.

psorowka commented 7 years ago

Did you intend to close the issue? Is it gone? I am quite interested in this since I wrote most parts of the transition from 1.x to 2.x :)

I still did not manage to reproduce it. I put both server and client into the same process, drastically increased polling interval, ... everything looks good and stable for here.

I think in order to narrow this issue down, you should try to reproduce the error outside of node red. it may very well depend on your implementation

biancode commented 7 years ago

Hi Peter, yes I closed it for now. ;) If I got some more - I'll be back ...