Yes I reproduced the issue with 3 clients on a local network but only with the release.
The debug seems more stable.
This is not really reproductible

Yes it looks like ok.
My server is still running on windows 10...
What happen if you connect a server with a fresh work file to all the running clients ? Does it stop ?

pfff... I have a server running since 30min in the debugger without problem...

I uploaded a new dbg release
May be a conflict between winsock.h and winsock2.h

So this is not a crash but an unexpected exit ?!?
I'm investigating....

So same behavior with the dbg exe and exit without a popup ?

I uploaded a new dbg exe

Do not kill clients

Ok thanks
no it is not compiled for more than 50 clients
i redo it

did you get the file from here ?
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
vc_redist.x64.exe

I added a debug release, hope it can bring some infos:
https://github.com/JeanLucPons/Kangaroo/releases/tag/1.5
Thanks to try as server...

I don't think the problem come from the network. When you restart the server, all 92 clients reconnect well, the server works a bit and crashes.
I will make further tests and try to reproduce the issue.


Yes as said above, it is an estimation and this estimation does not take in consideration the overhead of the DP method which is linked to the total number of kangaroo. The server does not know how many kangaroos are working.
And if you restart all clients, then it is like multiplying the number of kangaroo by 2 and stop the half of kangaroo which creates an overhead. I will also add the support of -ws for clients.

@zielar
Did you use the original server or a modified version ?
Could you also do a -winfo on the save28.work ?

Arg,
Hope there is no problem with a file bigger that 4GB !
The last save work printed a wrong size.
Do not restart clients and restart the server without the -w option.

Thanks

Yes my holidays in the mountains was vey good


The best choice should be made taking into account the total number of kangaroos.
You have to choose nbKangaroo*2^(dpbit) the smallest possible comparing to 2^58.5.
If you have 400GB of RAM, choose dpbit to have an expected RAM of 200GB max.

Hi there

@etar
I checked the client and server and I didn't manage to reproduce the issue.
If I break the network at the client side, the server close the connection after the timeout (5min) and when the client goes back it reconnect.
But I will add a http like connection mode and a way to set up the send period.
There is way to do that by setting the CLIENT_TIMEOUT to 3 sec and the SEND period to 10 sec for instance. You get the following output but it works.

Client side:
[180.22 MK/s][GPU 180.22 MK/s][Count 2^29.99][08s][Server     OK]
RecvFromServer(Status): Software caused connection abort
[140.52 MK/s][GPU 140.52 MK/s][Count 2^31.07][18s][Server     OK]
RecvFromServer(Status): Software caused connection abort
[140.34 MK/s][GPU 140.34 MK/s][Count 2^31.68][28s][Server     OK]
RecvFromServer(Status): Software caused connection abort
[141.10 MK/s][GPU 141.10 MK/s][Count 2^32.11][38s][Server     OK]

Server side:
Closing connection with 127.0.0.1:64273
[Client 0][DP Count 2^19.11/2^21.05][Dead 0][41s][19.2/49.5MB]
Closing connection with 127.0.0.1:64274
[Client 0][DP Count 2^19.70/2^21.05][Dead 0][51s][28.0/60.7MB]
Closing connection with 127.0.0.1:64275

@zielar

wow, 460000Mkeys/s, really ? #110 should be solved tomorrow...

I will be off up to the end of the next week.
I'll add the support for the -ws for client backup, this should avoid this overhead due to path breaking.
Good luck for solving #110

I need more tests.
I think path breaking (when you are not using -ws) can also impact but I'm not sure.

I'm not really surpirsed.
The key you search is the worst case.
When searching a key near to the border, you have only one half of tame and wild that overlap.
In that case you need ~22 times more DP than expected, this can happen
If you count the total number of jumps:
Each time you restart from scratch a program (or a client), you have the overhead of nbKangaroo*2^dpbit, this is the average time that each kangqroo produce a DP.
This is why you need an nbKangaroo*2^dpbit the lowest possible compare to sqrt(N).


To improve the search on the border it is possible to have a non uniform sampling and increasing kangaroo density near the border, it compensates a bit.

No there is no feedback yet from the server to kill kangaroos which collide in same herd.
This is tricky to implement but possible.
On the other hand, this kind of collision is rather rare (up to 2sqrt(N) total jumps) and if you start to have too much collisions, it is better to restart all clients in order to re-randomize all starting points.