It’s impossible to know without additional background on the history of the application or its author, which is either unavailable to you or you are unable to share. However there is a very good chance that this is just the result of a developer’s inexperience in any form of networking programming.
It’s not impossible, but I think that the chance of someone writing in-house corporate software in the late ‘90s who were also familiar with NCP (discontinued in 1983, before networks were common in all but the largest organizations) are really remote.
In the early ‘90s very few developers would have been experienced with network programming. Most people’s exposure to networks would have been limited to using (likely NetWare) file shares (*1). Technical resources and training were more limited and harder to reach than in today’s connected world. Your typical corporate in-house developer would have been primarily a domain expert, maybe self-taught in programming and writing programs for DOS standalone machines. They would have had perhaps one book available to them about how to program in TCP/IP and no expert available to lean against.
If you started writing a network application at the time (probably using Sockets) you would start coding right away, learning as needed without studying the protocol or library in full detail. Most of your attention would have been on the domain of the application, with the networking code being a small portion you needed to get working and then move on. You can go really far, even finish coding, without even realizing that there was such a thing as client ports. Even if the developer eventually noticed, there is a chance that they had been too committed by then to something that already worked, and decided to keep going.
I started my professional career in the late ‘90s surrounded by people who had more networking experienced than your typical corporate developer and maintaining a fairly sophisticated TCP/IP client-server application; and I still found several components that happily assumed that TCP/IP was packet-based (*2) and got away with it most of the time. The most well intended developers could get protocol concepts wrong. (I didn’t just show up with The Truth at hand of course, I was simply lucky enough to be given the needed time to study the documentation, then identify and fix the issues)
(*1) There is a small chance that they had been exposed to SPX/IPX network programming, but as far as I know SPX/IPX has a notion equivalent to TCP client and server ports, so that would not explain the misunderstanding. Someone correct me if I’m wrong because I have never actually written for SPX/IPX.
(*2) The assumption that (Winsock example) a single
recv() call will get you the full message you are expecting from the sender. That is not guaranteed. TCP is a stream protocol and the sender doesn’t send packets but a sequence of bytes; you’re getting a stream of bytes chunked (in order) for efficiency reasons, but you don’t control chunk sizes. You have to know the size of the message (in advance or from stream data), you have to keep reading until you get all the chunks of your message, and you have to reassemble them yourself.