Can any one confirm this networking tutorial, before I waste my day?

I am trying to get into networking. I want to do the simplest over-the-internet chat I can, before I attempt to add anything monogame on top…

So, all of the stuff I find is pretty old. Sometimes a decade+…

However, I have found one tutorial that looks nice, complete, and well commented…

Since it is several hundred lines of code, I would appreciate if someone with networking experience would glance over it real quick, and tell me if looks like it is still valid, before I waste my life trying to learn from it…

You dont have to sign off on it, and I wont hold you accountable for any failings…
Would appriciate any help :slight_smile:



Would also accept substitute tutorials, if you can verify them to some degree…

Usually XNA/MonoGame developers, C#, will refer you to the Lidgren.Network.dll

It’s probably a lot easier and quicker than writing your own base networking capabilities.

hmm… Sounds nice… will have to look into that…

For anyone following this thread, I’ll post back when I check out this Lidgren.Network.dll

@monopalle The sockets API allows for programming the Application layer in the network layer stack. Do note that with the Internet, the network layer stack is more practically: Application layer, Transport layer, Network layer, Data Link layer and Physical layer. Sockets is the interface that the application (or game) has with the operating system which has an implementation of the transport layer protocols (UDP or TCP generally). The links you posted go over the sockets API for C# & .NET. The Lidgren library is great as it does most of the heavy lifting for you, but it’s only works with the User Datagram Protocol. If you want to use the Transmission Control Protocol then you might want to go back to using the .NET sockets or find a different library similar to Lidgren which supports TCP.

You may also find this blog post from 2010, Choosing A Network Library in C#, to be interesting and relevant.

1 Like

Frankly, most of what you wrote seems above my pay-grade…
But I appreciate the effort, and its cool that you link to documentation.

What I understand, though, is that UDP is about maintaining the data flow in real-time, and TCP is about maintaining integrity of data, even if that means delay.

Pick your poison…

Perhaps the main lesson for someone like me, is to use this lidgren library, and be happy that I can program at a higher level than all that UBER technical gibberish taking place below… :frowning:

But before I continue, here’s a follow up question:
I guess TCP would be better for a chat program… But maybe its overkill, if I will eventually use UDP for games anyways…

If I use the UDP protocol for a chat program, will messages show up in proper sequence?

Do I run the risk of getting the “how are you” first, and THEN the “Hello”?
Or is this only a problem for high speed machine communication?

You can think of the Transport layer providing services to the Application layer for transmitting and receiving data between applications running on computers across the IP network. TCP is a protocol which has higher overhead than UDP but provides guarantee delivery, ordered, and duplicate protection of a stream of bytes. To make this happen TCP has to build a connection between two or more computers. UDP provides a connectionless service that does not guarantee delivery, ordering, or duplicate protection of data thus has lower latency than TCP at the cost of reliability.

Usually applications (and games) use both protocols but for different kind of data to be transmitted. For example, a login system to a multiplayer game should probably use TCP while syncing real time data between game clients should probably use UDP.

Thanks. Yeah, I think I get the rough idea of TCP vs UDP, I guess I should clarify my question a bit:

Is UDP reliable enough for a simple little windows forms chat program, with a handful of users? OR is that simply TCP territory?

I feel like I could code some measures to account for unreliable nature of UDP, like having clients time-stamp their sent messages, sending receipts, that sort of thing…

I’m not developing for commercial/public use or with security in mind… There would be no login, only the option to type a handle/username, maybe a field for entering a server address…

Well, with UDP, “packets” may arrive out of order or fail to be delivered all together. Simplistically speaking, TCP detects when his happens and handles the problem for you. I wouldn’t use UDP for a instant messaging application since it wouldn’t be a good user experience to have a user’s message dropped or received by other users in a different order relative to other incoming messages. For the instant messaging application I would have a TCP connection between the client and the central server for each user and then it’s the server’s responsibility to relay the messages to the other clients. For games like first-person-shooters that have to sync player positions constantly as they move it’s probably better to use UDP for example because it would be reasonably acceptable if one game frame out of a couple hundred were out of sync for a split-second at the benefit of having lower latency.

Thanks for sharing! … TCP it is…

Sad panda, I was almost starting to like lidgren, just from reading about it :slight_smile:

Lastly, are you aware of any popular / well documented library that provides TCP instead?

I have used these tutos at work and apart some code that has to be updared in regard of the. Net version used they are ok.
But it is a really basic chat. You will have to handle the mechanism of disconnection of a client by yourself, i mean gracefully disconnect.
It is a good starting point to learn, but for a good chat there is a lot of work. I have used it to test multiple clients and tcp connections and based on that, rewrote it entirely to fit the needs at work.
If i remember well, some methods of sockets are not used and other not optimal (speed and reliability of data was the main concerns) and you will have to handle some threading mechanisms in order to not freeze the display when for ex a big picture is sent if you intend to transfert files.

To conclude: not a “real” async sockets tutorial to base a work on, but ok to learn sockets.

1 Like

Great Alkher, nice to know it works at least…

You wouldn’t happen to have a link to something even better, or perhaps a free and open library to use?

The best ones for me are from the msdn, where I gathered a lot of examples and information to improve upon your tutorial.
look for
c# async socket tutorial
on google, there is the client one, and the server as the 2 first links (for me at least).
Both use async methods (BeginAccept, End accept, etc) to avoid app freeze for long operations.

Nice. I’ve had trouble following MS dev stuff and documentation in the past, but your examples seem manageable…

Do you know if there is something external to the code that I need to do on a standard end user machine, like setting up ports or changing windows settings? -Or can I expect to run programs like this right out of the box…?

Opening the ports should be the only thing needed, as by default all should be closed excepts the used ones.
Maybe check also the router for the NAT, depending on the box you have as your ISP.

One tip to debug the client and the server at the same time on a single computer: use the localhost, and open the solution two times, on one set the server as the startup proj, on the other the client. But don’t forget to build the server first if you share the sockets’ code in a library between both projects.

Scanning the code for port numbers, I found this line:

private const int port = 11000;

and later this one:

IPEndPoint remoteEP = new IPEndPoint(ipAddress, port);

…But to make sure: This will not in fact open port 11000, I have to go into router settings and do it manually? On every end-user connection?.. And then close them when done, or…?..

Hope my questions seem reasonable… Its hard to gauge the scope of this stuff with zero prior experience.

I hope this is relevant:

NOTE: it is OPEN SOURCE :pizza:

[EDIT Err that URL of his is a bit… yeah let’s not mention it ]

I didn’t see it mentioned in this thread but you can do “reliable” UDP. Usually the library you use will take care of resending any lost or packets and ensuring correct order on the other side. Lidgren supports this.

Note first person shooters, fighting games, and even MMOs use UDP… even for chat. They just ensure the packets are sent reliably when needed.

Also worth mentioning FalconUDP is an alternative to Lidgen which is made by the same team that developed the game Square Heroes using MonoGame.

@monopalle I was asking the same questions about Lidgren a few weeks ago on this forum, the differences between tcp/udp etc just like you, I’m also new to network development. I came to the conclusion that Lidgren is good enough for our needs - even for chat. Yes TCP is slower and more reliable between packets, but from my understanding of Lidgren he has done some cleaver stuff in there that you can basically have the same affect as TCP.

_client.SendMessage(outmessage, NetDeliveryMethod.ReliableOrdered);

If you use the “ReliableOrdered” delivery method as in the above example, then this basicalls acts like TCP - so for messages you need to send and ensure they are in order (chat) then use this method - for messages that you don’t mind going missing (e.g. movement?) then use a different delivery method.

Here is the thread I questioned in, SpiceyWolf has also done a library which he offered me:

Hope this helps.