the file transfer feature has internal limits to avoid congestion, especially with many clients. It currently sends chunks of 256 KB every 25 ms, i.e. about 10 MB/s. Can you confirm similar transfer rates? We might add configuration options to configure the chunk size and send interval in the future. If this is urgent to you we can prioritize the development on a commercial base - contact email@example.com to discuss further details.
The demo mode uses unicast in order to work across subnets. It's therefore not suitable for video playback.
In a Ubuntu 18.04LTS environment (Veyon 4.3) you can achieve that goal by means of scripts acting on the firewall (iptables) of the local machine. One script is used to create the desired rules to block/modulate internet access and the other to flush all the applied rules, thus giving full access to internet. You should also modify the sudoers file to give the client users the privileges to execute the scripts with root privileges without being prompted with a password request.
Finally in the veyon master you must add both scripts in the list of the executable programs, so that you can remotely launch them in the clients.
One limit of this approach is that an expert user could find the scripts and get internet access launching the unblock script in the terminal.
To make sure no one could enter a Teacher's computer and to make it easier for us, we just selected the option "Restrict access to members of specific user groups" and we left the "Authorized user groups" empty. It worked really well, and now no one can access a Teacher's computer.
But a new problem has arised, and it is a constant flickering of all of the screen items (windows, menus, sidebards, ...) from all other apps running (we are using Windows 10). When we select back the previous configuration option "Grant access to every authenticated user" the flickering stops.
(Update: Flickering also happens if I move all the groups to the "Authorized user groups" and also if we select the option of "Process access control rules" (even with no rules at all). The only option that makes no flickering happen is the default one - "Grant access to every authenticated user" )
Any idea what could this be?
We want to configure the system so no user can access a teacher's computer while he/she is working on it.
Do I understand correctly that veyon 5 actualy WILL be a webbased application that can be hosted on a server?
To come back on my initial request. My intention is not to regulate a server invironment, but use a server to host veyon so the desktop environment can be managed from a central location.
IMO running veyon on a desktop is sub optimal since that desktop is probably used by a single user, for example a teacher. He or she can start the application and manage the classroom, but what if the teacher has no permanent classroom? What if there are multiple classrooms to manage? Install veyon on every single teacher computer? (desktop or laptop)
I think a central install on a server where teachers get permissions to manage a classroom would be (especially from an admin point of view) highly preferable.
What are the current insights on the (near) future of veyon?
How can I broadcast the screen of a student to all other screens?
If you want to transfer a student’s screen instead of your own screen in demo mode, first activate demo mode for all computers. Then stop demo mode for the student to be performing the demo using the context menu. Finally open the remote view for the students computer. This will transfer the remote view window - and therefore the student’s screen - to all other computers.
There is also an issue that students are given multiple prompts for access when performing single actions, especially monitoring.
If the student selects "Yes" to all these prompts instead of always allow, the instructor can lock the machine, and the student becomes unable to approve the next prompt that comes up when the instructor tries to unlock it due to the interrupt driver.