Anyone running a server for Gr8net?

that reminds me of artrags demo/unfinished game https://www.youtube.com/watch?v=RypGMBsO540

Would love to play such a game

I plan to support network cards in MSXgl, but I need to find one first to test.
Once the library is done, it shouldn't be hard to make any kind of network game.
The biggest problem will be on the gameplay side to synchronize data and manage lag.

For the moment, I can't help you.

Absolutely support it. Unless we use some special protocol (e.g. MQTT) through newly added UNAPI.

My Fusion-C libraries are here. If your compiler/library distribution is already having them, use the ones from distribution because mine are first release (and I did not hear about bugs and fixes back so far).

For making the multi-player game I propose making new forum thread. In the early era, when I was making DURAK game Edoz and I were trying to make chat and turn data exchange, but, unfortunately, did not finish it :( but ideas are still here!

Obsonet does support UNAPI TCP-IP indirectly if you install a driver made by Konamiman (Internestor Lite) and most, if not all Obsonet users, already have it running UNAPI TCP-IP, I've got quite a few reports back from Obsonet users that use my Telnet client and my menu driven MSX HUB Client, both only support TCP-IP UNAPI. Also, the image of Bluemsx disk I've shared on that post/video uses internestor lite so you can use it with UNAPI TCP-IP.

So, supporting UNAPI TCP-IP with Eugeny wrapper supports Obsonet, Denyonet, Gr8net, SM-X/SX2/OCM Wi-Fi and the future XSWIFI by Xavirompe when it is released. The only unsupported commercial adapter would be BadCaT (which I've planned to make an alternative esp firmware and unapi driver but unfortunately have not had time, but I think Alexander Sharikhin, the author of moonrabitt gopher client, made a firmware and driver that supports active tcp-ip connections through unapi, https://github.com/nihirash/esp-binary-firmware, anyway BadCat regular release is mostly for telnet so wouldn't work for games as is)

I think that the most active user base of msx network software based on my experience talking to users of my softwares is split between Obsonet and Gr8net users... A distant third place is comprised of users of my WiFi solution for SM-X/SX2/OCM devices, even though all SM-X and SX2 support it out of the box, most users of those fpgas didn't install the driver or bios as they have no interest on networking, just want to play games from their childhood (and who can blame them? :P).

One thing to take into consideration is that those solutions might use vdp interrupt time. Obsonet for sure is the one that uses most cpu on interrupt time, I know Konamiman made all efforts to make reasonable use of cpu during interrupts but there is no miracle, tcp-ip is 32 bits (4 bytes address) and implementing the full stack over raw network is kind of a small miracle that Nestor operated... That is the reason why it is difficult to get much more than 7KB/s with it if not saving on disk, and 3.5KB/s if Saving on disk or doing other stuff as well (but a Game probably wouldn't need to move large quantities of data, so that should be good enough). My WiFi solution uses very small amount of time hooking vdp interrupt just to increase an internal time-out counter, other than that cpu is used only on functions executed mostly moving data from the fifo to the desired ram location, and its performance is about 35KB/s just moving to memory and 15KB/s saving on disk, on turbo cpu speed of OCMs it can go up to 70KB/s just ram and 35 KB/s saving. I don't know the gr8net unapi driver internally but it is very high performance as well (probably the fastest solution, I don't have the numbers as I don't own one, but per some friends testing I think it is at least 10 or 20% faster than my Wi-Fi solution) and I would guess it doesn't use vdp interrupt time or if it uses, should use it for small tasks like my driver does. Denyonet is a total stranger for me, I know about it, know it has tcp io acceleration, it uses the same chip as gr8net for network but it doesn't have a fpga helping to alleviate work from z80, my expectation is that it would have a performance between Obsonet and my Wi-Fi solution. And Xavirompe XSWIFI should have close to the same performance as my solution or be a little bit faster since he doesn't use serial communications.

Sorry if more details than you need, I tend to talk too much, if you have any questions I'll be glad to try to help you, UNAPI support is something I would love to see on all libraries and I've been working myself on trying to make unapi support better on existing applications and easier for new applications (I've made a library version of Konamiman hget so applications can support http easily, with support to progress bars, callback functions to handle incoming data or saving directly to disk, etc), that is something I do just because I really like the idea of network support on msx, because the user base itself is not really huge (perhaps it will improve someday if somehow we get a Tcp-ip unapi implementation working on OpenMSX, that surely would boost the user base and encourage people to try networking software for msx ;))

The major difficult doing an online game for MSX is latency... z80 is not a really fast CPU and most games have CPU time used almost entirely. The way UNAPI is made, it is a polled API, that means, you need to keep requesting to receive data (not possible to have a callback registered as an example). Also, if you support OBSONET, you will be extra doomed with lag because the TCP-IP calculations/protocol is done on the z80 as well (other cards do on the interface themselves, so you mostly just get the data), which is done a few packets every VDP interrupt, so you need to wait VDP interrupt so Internestor proccess it, then the next VDP interrupt you will read again and receive the packet... My guess is that latency won't be really nice with obsonet, with other adapters it might be lower and if you do not need too much data being transferred, you should be fine, but if too much data (i.e.: 100 bytes if you just send OTIR and some small commands, would take .5 to .6 ms, but 1KB would take 5ms!) you might get issues too... If you plan very well to use the least possible ammount of data to transfer, perhaps it is feasible, but remember you don't need just to receive/send data, you need to process it and take actions based on that, you need to sync stuff, etc... It is for sure a great challenge for anything that is not turn based