How Monitor Hash Dice Socket Time Out?

[Money_Magnet]

Guys do you know if there's  a way to know when the socket will time out on Hash Dice? It sucks that it times out exactly when I am at a loss and I need some time to recover. Is there a way to know when the socket will time out so I can pause my script until it does?

[Skele]

did i answer this already. like most networking things you don't pause until ready, you try and then handle the exception.  That is because it is found to be one of the simplest yet most efficient wants to deal with communication bottlenecks.  Originally in routers all they used to have everything going through a fifo queue.  But they found that could greatly increase their throughput by just firing and waiting for an ack back or an exception  and making the client be repsonsible for retrying.

 

so in your case since the socket timeouts are undoubtably coming from the back that there are more 5 threads betting at once or something similar the best thing you could do is to handle the promise properly.  Essentially if you succeed you handle the results of the success, if you fail you just try to replace the bet or whatever is failing.  Idealing you would only retry on exceptions you know are transient but i don't have a list of those that you might encounter.  I am also fairly sure there is sock handling methods in the ss object which also holds details about your user and the their wallets etc...

 

function doBetOrSomething()

{

     if(!isCanceling)

   {

     lbg.bet(0.00001).then(function(r){ r.payout > 0 etc........ this is your success case }).exception(function(e){ this is where you do your error handling and should recall           into      this method to retry the bet. doBetOrSomething()});  

     }

}

[gwbE-Whore]

On 5/10/2022 at 5:38 PM, Skele said:

did i answer this already. like most networking things you don't pause until ready, you try and then handle the exception.  That is because it is found to be one of the simplest yet most efficient wants to deal with communication bottlenecks.  Originally in routers all they used to have everything going through a fifo queue.  But they found that could greatly increase their throughput by just firing and waiting for an ack back or an exception  and making the client be repsonsible for retrying.

 

so in your case since the socket timeouts are undoubtably coming from the back that there are more 5 threads betting at once or something similar the best thing you could do is to handle the promise properly.  Essentially if you succeed you handle the results of the success, if you fail you just try to replace the bet or whatever is failing.  Idealing you would only retry on exceptions you know are transient but i don't have a list of those that you might encounter.  I am also fairly sure there is sock handling methods in the ss object which also holds details about your user and the their wallets etc...

 

function doBetOrSomething()

{

     if(!isCanceling)

   {

     lbg.bet(0.00001).then(function(r){ r.payout > 0 etc........ this is your success case }).exception(function(e){ this is where you do your error handling and should recall           into      this method to retry the bet. doBetOrSomething()});  

     }

}

 

 

This is the dumbest reply I could have ever expected to see in response to the OP's question(s).

[Skele]

You mean to say it must be over your head because so far you have posted no replynof value to anything in the forum right?