Whats wrong with HQ domain and metavoxel server?


#1

The terrain keeps coming and going. at the end im tried to open the log file. and around that time interface.exe crashed with a runtime error. Log is to long to paste it. firefox crashing :open_mouth: so here it is as pastebin http://assets.sqmv.nl/log-HQ-20150108.txt


#2

That looks like a networking issue I discussed with @philip

If so, what happens is the client disconnects then has to re-download the metavoxel terrain (since it’s not cached) leading to flickering terrain. From the client side it looks as if the MV (and/or other services) are being turned on/off repeatedly while from the server side it’s clear that the client is dropping connection.

The interesting thing is that I’m not seeing this with stack running on Mac but am seeing it while running on Linux. In all cases Interface here is on Windows.

It also, again, seems related to Interface not being the foreground window and that leading to some change in the packets per second rate stack expects to see and or sync issues. The real oddity is that this previously occurred regardless of stack being on Mac, Linux or Windows - now, for me, again, it’s fine with stack services on Mac but not on Linux. Back to tracing with wireshark again. There still seems to be some ugly and subtle error in the networking/timing that seemed to have been fixed on Jan 2 but now has, partially returned as of Jan 7/8.


#3

Just did a quick experiment. Here’s the setup. Interface 1719 on Windows 7 64 bit.

Domain Heron - remotely located running latest Mac OS X assignment/domain stack.

Domain Jungle - located on my LAN running latest Linux assigment/domain stack.

Move to location in Heron with no entity or metavoxel in view/rendered. Jungle is a clone of Heron for metavoxel/entities. (Also tested while in view of entities/metavoxels with no difference seen to results).

At all points I’m able to see the “DOS window” for Interface console output.

While in Heron I see no error output in console regardless of Interface being the active (foreground) application or it being in deselected idle mode.

Move to Jungle - all is well until Interface is not the active window. Console is flooded with;

[DEBUG] [01/08 14:45:42] ERROR in writeDatagram: QAbstractSocket::NetworkError - "Unable to send a message"

After some time - around 20 to 30 seconds the volume of messages accelerate - there’s a disconnect from server stack and it begins again. As long as Interface is not the active window this continues.

From the server side you see the agent doing a disconnect/reconnect cycle, but, at no time do you see the stack processes restart. The timers for all 4 stack processes indicate no restarts while the agent is lasting about a minute (max).

Next step is to do some network tracing, but, it’s very odd that this is not consistent regardless of stack being on Linux or Mac as it seems client side, but, obviously, there’s something server side to it.


#4

Repeated my experiment with stack running on a remotely located cloud droplet - same linux setup as on LAN (Ubuntu 14.10 64 bit - same libraries, git level pull as LAN setup). Resulting in - works perfectly - so what I’m seeing has something to do with being on LAN to LAN Interface <-> Stack vs Interface here and Stack elsewhere.

Spent some time in HQ domain and saw no errors there. Ping time for audio/avatar/entities at 80(ish) with the cyclical bumps to 400(ish) every 10 seconds or so. Had no drop outs of terrain or disconnects regardless of Interface being selected or back ground application.