In my experience, not a good idea to write both the client and the server for a given protocol which use each other. Far too easy to misunderstand the protocol. I remember doing this for a training course I wrote for OLE (later COM) years ago. The client and the server worked perfectly together, just not with correctly implemented OLE clients and servers.

▲

snerbles 2 hours ago | parent [-]

Just slap a new legally-distinct-but-still-confusing name on your client/server pair, and use it as a marketing tool to sucker in purchasing managers.

Like EtherNet/IP, where the IP somehow stands for "Industrial Protocol".

	▲	zabzonk an hour ago \| parent [-]
		Ah, but what if one your clients needs to use, let us say, Excel... My mistakes with the training course code would have been fixed if the company would have bought Excel licenses fof our customer workstations. And I just remembered it was DDE (dynamic data exchange), not OLE. OLE was much better specced than DDE. Like I said, it was way back when. But the basic rule (don't test using both a home-grown client and server) still applies.