Show HN: TCP chat server written in C# and .NET 9, used in the terminal
github.comIs this effectively IRC? I know it's not literally compatible but the same basic TCP for chat right?
ETA: Not being dismissive! Cool project!
Admittedly I don't know a lot about networking or IRC clients, but in practice I believe so. The idea was to implement the simplest possible way for 2 people to communicate via TCP.
wow, a simple project made by chatGPT reaches hacker news top page. Way to go C# devs! And yes, I am one of them.
It's a simple project but it doesn't have the usual AI code style to me. It reads instead like someone getting the hang of networking in C#. Incidentally, this is OP's first public C# repo.
https://github.com/Sieep-Coding?tab=repositories&q=&type=&la...
yeah maybe, I guess it's fine, I meant no disrespect for the person learning. I can see some git issues so probably a new dev showcasing.I just don't understand how the hn posts work. Shouldn't there be some upvoting of stuff to be on the main page, or it was just released so it appeared?
For what it's worth the HN algorithm is a pretty complex, so I'm still oversimplifying but ti's more about the rate a story gains score than the points themselves. You can get just 5 votes in the first minute you're up and make the front page, which is more or less what this did.
I used Rider's auto-complete for a lot of the code but it is handwritten.
What happens if the message entered by the user into the Client is more than 4096 bytes?
From what I see, the code is incorrect in reading “messages” from TCP socket stream, and will be failing randomly in production with messages longer than 1500 bytes, and also sometimes when even shorter.
Instead, the TCP socket must be treated as a stream of bytes, and use either some delimiter as message boundary (like \n, while escaping any newlines inside JSON), or write message size before the message bytes itself, so that the code knows how many bytes to read until full message is read.
Edit: to clarify, TCP protocol does not guarantee that if you write some bytes in one go, they will be read in one go as well. Instead, they may be split into multiple “reads”, or glued together with the preceding chunk, or both. It’s a “stream of bytes” protocol, it only guarantees that written bytes come one after another in the same order.
So the “naive” message separation used in code above (read a chunk and assume it’s the entire message that was written) will work in manual tests, and likely even in local automated tests, but will randomly break when exposed to real network conditions.
Good write up, thanks for taking the time to go into detail. I may try to implement your feedback at some point.
Thanks - I had a quick scan through the code and noticed the 4096 byte buffers and wondered how larger messages were handled and couldn't see anything but wondered if I was missing something!
love that its single file each for server and client. simple and neat.
Thank you! I think it goes against Microsoft's C# conventions a bit (i.e. the classes should be separated out more) but I prefer this setup.
Funny, C# app only tested on Linux
I remember having seen that Linux is used a lot by Microsoft's .net team.
Linux is the best platform anyways to run your .net core application. With Avalonia you have a good cross-platform solution, albeit that they still depend on X11/Xwayland for Linux.
A shame .net isn't more popular. The MS branding is a problem though. Although .net core is MIT-licensed, most contributions are from MS¹. Still, if MS would ever ditch it (quite unlikely for the foreseeable future), I think the ecosystem will step up.
__
1. F# is an outlier, that is a real community project with lots of contributions from companies and enthusiasts
I highly recommend trying C# on Linux, it works fantastic. Rider on Linux works amazing as well so hats off to Jetbrains.
This is fairly normal these days, no?