You don't have to have a server to use tcp/ip at all, just the computers on the same network sigment/subnet. Just set a static IP addy for each system.

BloodyCactus wrote on 2021-08-14, 02:05:

is speed even relevant tho? we have 1, 2.5, 5gb ethernet now. your encapsulating an ipx packet system designed for dos games on 10mbit on home lans running bnc with t connectors and loads of packet collision.

I dont think it matters about speed of udp over tcp anymore knowing what the target was designed for.

Speed is very relevant if you're running an app that was originally designed for a LAN over a WAN. The latency is nearly always going to be far more than an old 10mbps link and TCP compounds it by using a sliding window.

^Latency is a core problem for emulating things such as the Gameboy Link Cable.
Even 8-Bit machines required low-latency connections,
which even today most of the internet connections simply fail to offer.
So emulators still have to perform some magic hackery to get things working, at all.

I doubt the speed of the network link is going to make a difference on DOS games, whether TCP, UDP, or high speed networks are used.

From the perspective of a programmer, the network was another slow device to deal with. If the network started magically responding 100x faster it probably wouldn't affect the game in a negative way, as network communication is inherently asynchronous. (You fire a packet out as you need to, or you get the interrupt when one becomes available. You don't sit and do anything timing sensitive that depends on packet arriving because you have no idea of when that will happen. Packets drop. Timing is affecting by other things on the network.)

Also remember that back in the days of 10Mb/s Etherne people were using hubs, which were subject to collisions. That problem basically doesn't exist anymore since everything is connected to a switch now.

Except for null-modem connections, maybe, which were the original way of setting up multi-player/two-player games.
Unlike IPX/SPX and modems ("Dial-up connections usually have latency as high as 150 ms or even more"; Wikipedia), 16x50 FiFos were quite quick.
According to the web, RS232 latency can be as low as 2ms and as high as 1000ms, depending on the situation.
This guy says he has a 20ms latency at 9600 baud, for example. Many internet connections have ping times worse than that.
https://forums.ni.com/t5/LabVIEW/Delay-over-R … ile.language=en

jmarsh wrote on 2021-08-14, 00:00:

I think you might run into trouble using UDP.
Even though IPX didn't guarantee reliable delivery (same as UDP), in practice it was fairly safe and a lot of games that used it assumed there would be no (or at least very little) packet loss. They also tended to "spam" lots of little packets very frequently without any sort of collation (the sort of behaviour the Nagle algorithm was designed to reduce for TCP) and expected them to arrive complete and in order.
Both of these issues can occur with UDP, especially when there's a large amount of hops between the destination and source e.g. a trans-continental connection rather than a simple dorm room LAN.

UDP on the same network segment should be comparable to IPX. UDP is routable and has more overhead, but the the chances of packet drops are significantly less when you stay on the same network segment. UDP packets were more likely to be dropped years ago when routers and switches were less powerful; it is unlikely that modern hardware will drop a UDP packet because it ran out of buffer space.

Nagle's algorithm makes TCP/IP more efficient, but at the cost of increased latency. I didn't implement it in mTCP, as the program has more control over how packets get pushed out. mTCP will combine several empty ACK packets into one outgoing packet to cut down on overhead, but only if those packets have no data in them. That was easy to do compared to the full Nagle algorithm.

But the key phrase there is "on the same network segment" i.e. a LAN. I'm talking about a WAN, where UDP packets will absolutely get dropped if you spam a bunch of them in quick succession.
The same effect DOES happen on a LAN if you send a lot of multicast/broadcast packets, which is also something old games liked to do.

jmarsh wrote on 2021-08-14, 23:08:

But the key phrase there is "on the same network segment" i.e. a LAN. I'm talking about a WAN, where UDP packets will absolutely get dropped if you spam a bunch of them in quick succession.
The same effect DOES happen on a LAN if you send a lot of multicast/broadcast packets, which is also something old games liked to do.

Since my program will be the middle-man between the network and the game, I could also introduce some sort of packet control so that if the game tries to spam the network, the program could hang on to the packets for a period of time, then again that may be asking for poor game performance.