Ok here is a list of (very) bad bugs using boygrouping.
If a client tcp connection fails, vvvv keeps on trying connecting to it. So the server appears to hang, but by using network monitor we can notice it just desperately tries to send some packets to the client. Should have some timeout and disconnect connection, log message instead, since for the moment any small loss of connection makes the system pretty much unuseable.
Memory (or absence of) management needs a huge improvement.If we start a decently big patch, then start the clients, we have a huge memory leak on a per client basis (the more client the higher memory usage). If we start clients one by one we have the same effect since memory is not freed anyway. That makes it impossible to start decent big patch that way (23 clients), since it goes out of memory all the time. Only way for now is to start a minimal patch, start all clients, then open the big patch (which gives the issue if a few clients disconnect for some reason we have to restart the whole system).
Any patching has memory leak, which is also higher depending on client count (with or without Undo on/off). Simple way to replicate this, boygroup a patch with a decent amount of nodes, CTRL+A to select all nodes and move with keyboard, you should see memory growing quickly.
Startup behaviour is quite unpredictable, when we open all clients, in most cases we’ll have a few clients which fail to connect. If connection failed, client should be able to try to reconnect every N seconds. This makes it very painful to have a solid startup when nobody knowing 4v has to manage the installation.
Seems 4v sends a pretty big amount of TCP messages, even when not patching (and no setpatch is on either). I’ll try to have a cut down version showing that.
We discussed connection problems recently on IRC and Elias said, that it should be somehow fixed in the latest git commits. I will test this on the current week, but if you already tried and it’s not working - that’s bad.
By the look of it seems connection is working (can’t fully confirm yet), but now got some error messages in some animation filters, so feeling bit worried to leave those in installation (have to access remotely for now)…
it seems that the client not properly connecting to the server issue was introduced with beta30 and was fixed about 3 weeks ago in alpha builds. this should address point 4) you mentioned in your intial post vux.
also with beta30 a client wouldn’t reconnect anymore after the tcp connection got lost. this should be fixed as of yesterday by reintroducing ping messages from the client to the server every few seconds. was removed with beta30 to reduce network traffic, but after a long debug session yesterday there seems to be no other way than writing to the tcp socket in order to check whether a connection is still alive. not sure if this one was mentioned in one of your issues.
ad 1)
we can reproduce this issue by setting the boygroup broadcast mode to tcp. after removing the network cable, the server starts to hang for a very long time (~10-20sec) after a few seconds. depends on how much data is transmitted each frame from the server to the client. this behaviour isn’t new and can be observed in all vvvv versions we’ve tested (back to beta22), which of course doesn’t mean it’s a desired behaviour. but circumventing it would probably mean quite some amout of work i fear, as the library we’re using for networking doesn’t support writing with a set timeout. so i’ve to ask is this the setup you describe? or did you use udp in the first place and still experienced a server freeze?
broadcast mode of boygroup server node is set to tcp
a message supposed to go over udp but exceeding an overall length of the UDP package size (defaults to 1472) will be sent over tcp - reason for this behaviour (simply put) is that udp messages larger than that size get fragmented and many routers block fragmented udp messages - so it was decided to send them over tcp and write out a warning instead of to not sending them at all - for details see boygrouping basics#warnings
now if for any reason the connection to the client breaks, the socket won’t know about it immediately and will happily accept new messages until its internal buffer is full in which case it will block until a certain timeout value is reached -> that’s the experienced freeze like described in 1)
in case anyone else (vux already knows about it now) is experiencing freezes, have a look at the Warnings and Clear Warnings pins of the Boygroup (VVVV Server) node, which will tell you if a message got send over tcp and not udp and try to avoid sending too much data over one connection (not more than 180 values for example).
for details see boygrouping basics#warnings
