Socket error when using CycleTLS about cycletls HOT 13 CLOSED

Error: listen EADDRINUSE: address already in use :::9119 happens because you are calling initCycleTLS(); multiple times (remember this is not necessary because anything passed to the first instance created will be handled by the internal Golang queue).

if you want to do this you need to pass a different port to it e.g. const cycleTLS = await initCycleTLS({port: 9118}); or some port other than 9119

from cycletls.

CycleTLS has an internal worker queue system. You don't need to close the connection or call cycleTLS.exit(); after each call. If you want to cleanly exit at the end you can use Promise.all() like in the example in the docs.

I would say for repeated requests you can just not call exit and this error should no longer appear.

from cycletls.

CycleTLS has an internal worker queue system. You don't need to close the connection or call cycleTLS.exit(); after each call. If you want to cleanly exit at the end you can use Promise.all() like in the example in the docs.

I would say for repeated requests you can just not call exit and this error should no longer appear.

I am using CycleTLS asynchronously.

from cycletls.

Right, CycleTLS has an Asynchronous internal worker queue system.
This means asynchronicity is actually handled on the Golang side regardless of the JS implementation.
If you make sequential calls to CycleTLS the requests will be processed asynchronously and returned as soon as Golang processes the request.

as an example of this

const initCycleTLS = require("cycletls");

(async () => {
    const cycleTLS = await initCycleTLS();
  
      let response = cycleTLS('http://httpbin.org/delay/2', {
        body: '',
        ja3: '771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-51-57-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256-257,0',
        userAgent: 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0',
        proxy: ''
      });

      response.then((out) => {
        console.log(out) //Will always console.log second because of the delay
      })
      response = cycleTLS('http://httpbin.org/user-agent', {
        body: '',
        ja3: '771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-51-57-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256-257,0',
        userAgent: 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0',
        proxy: ''
      });
  
      response.then((out) => {
        console.log(out) //will console.log first because the request time is faster
      })
  
  })();

You will notice that the delay/2 response will always log to the console second even though it is called first. This means that CycleTLS responses are always returned as soon as they are processed regardless of the order they are called in. Unless of course they are awaited.

from cycletls.

Right, CycleTLS has an Asynchronous internal worker queue system.
This means asynchronicity is actually handled on the Golang side regardless of the JS implementation.
If you make sequential calls to CycleTLS the requests will be processed asynchronously and returned as soon as Golang processes the request.

as an example of this

const initCycleTLS = require("cycletls");

(async () => {
    const cycleTLS = await initCycleTLS();
  
      let response = cycleTLS('http://httpbin.org/delay/2', {
        body: '',
        ja3: '771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-51-57-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256-257,0',
        userAgent: 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0',
        proxy: ''
      });

      response.then((out) => {
        console.log(out) //Will always console.log second because of the delay
      })
      response = cycleTLS('http://httpbin.org/user-agent', {
        body: '',
        ja3: '771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-51-57-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256-257,0',
        userAgent: 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0',
        proxy: ''
      });
  
      response.then((out) => {
        console.log(out) //will console.log first because the request time is faster
      })
  
  })();

You will notice that the delay/2 response will always log to the console second even though it is called first. This means that CycleTLS responses are always returned as soon as they are processed regardless of the order they are called in. Unless of course they are awaited.

So what do you think is causing this Socket error?

from cycletls.

CycleTLS has an internal worker queue system. You don't need to close the connection or call cycleTLS.exit(); after each call. If you want to cleanly exit at the end you can use Promise.all() like in the example in the docs.

I would say for repeated requests you can just not call exit and this error should no longer appear.

This did help the error occurs less but it did occur after about 45 mins of continuous calls.

from cycletls.

Got it, yeah then there's a bug, something is killing the web socket connection without cleanly exiting internally. If you could provide some code that reliably reproduces this I can investigate.

Under the issues tab there's a template for bug reporting. If you could provide the information requested in the markdown template that could help as well.

from cycletls.

Got it, yeah then there's a bug, something is killing the web socket connection without cleanly exiting internally. If you could provide some code that reliably reproduces this I can investigate.

Under the issues tab there's a template for bug reporting. If you could provide the information requested in the markdown template that could help as well.

I will upload some code shortly that accurately shows you what I am trying to accomplish but another error I get when I take away cycletls.exit() altogether is this error: Error: listen EADDRINUSE: address already in use :::9119.

from cycletls.

Error: listen EADDRINUSE: address already in use :::9119 happens because you are calling initCycleTLS(); multiple times (remember this is not necessary because anything passed to the first instance created will be handled by the internal Golang queue).

if you want to do this you need to pass a different port to it e.g. const cycleTLS = await initCycleTLS({port: 9118}); or some port other than 9119

Thank for the support! Great module you have here!

from cycletls.

Error: listen EADDRINUSE: address already in use :::9119 happens because you are calling initCycleTLS(); multiple times (remember this is not necessary because anything passed to the first instance created will be handled by the internal Golang queue).

if you want to do this you need to pass a different port to it e.g. const cycleTLS = await initCycleTLS({port: 9118}); or some port other than 9119

Now I get a new error after some time Error: panic: runtime error: invalid memory address or nil pointer dereference.

from cycletls.

code?

from cycletls.

This may be related to this Ja3 Token Parsing error but I cannot bugfix something I can't reproduce.

from cycletls.

Addressed by this PR. Feel free to open another issue if you experience errors.

from cycletls.