Am 18.07.2016 um 13:42 schrieb Denis Kudriashov <dionisiydk@gmail.com>:
Thank's
2016-07-18 12:19 GMT+02:00 Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>: Awesome! I'll immediately will stop all my important work and start playing with it. I'm really interested how it will perform over high latency connections.
Yes, please report your experience.
Currently all optimisations are done on minimizing network communication without tools modification. So debugger is same GTDebugger but communication is configured accordingly to debugger behaviour. For example when debugger requests suspendedContext of remote process server returns context proxy together with method, receiver, receiver class name and other properties which debugger is going to use. Other optimization could be done on protocol level. Now transferred objects are traversed twice: by Seamless and by Fuel. It could be merged somehow.
Ok, I experimented a bit with network qualities. I just tested connecting and executing 3 + 4 on the remote side. Connecting transfers already 2-4kb of data which should add some latency when the network is bad. Local wifi and DSL connections work ok for the simple case because latencies are low. On a 3G network it can take between 4 and 7 seconds to establish the connection and around half a second to execute 3 + 4. I defined a bad mobile network with 20kb/s bandwidth, 10% packet loss and a delay of 100ms in transmitting. This is equally for down and up directions. The connection time raises to 11 seconds and the execution of 3 + 4 to 4 seconds. In order to be able to test I needed to tweak BasysNetwork>>#initialize to set a timeout greater than 45 milliseconds which is pretty low. Usual timeout settings for browsers and mobile applications are around 30 seconds. I raised it to 10 seconds in order to test the bad network. To me the results are more or less expected. Well, I hoped they would be much better :) It works reliably even over slow networks. The main problem is that when it comes to remote debugging environments or browsers the number of message sends is quite high. So it is to see what kind of environment these tools can serve. For sure there is plenty of space to optimize (I hope). I did the tests with bad/mobile networks just get a clear mark where it cannot be used. To me personally the benchmark is DSL upload speeds. If it is doable over these (could be 256k/s) I can connect from the office (DSL down) the my little devices at home (DSL up) ;) Anyway, it is a wonderful tool I was waiting for so long. Thanks, Norbert