Hi ,

I am new to c# . I want to develop a simple lan messenger which shud be something like "ip

messenger" . where you dont need any seperate server. Please guide me how to acheive this.

It shud be a single exe file which on opening shud list all the connected people (ppl who

opened this exe file on another machine , instead of all those who are connected in lan).

The user shouild be able to select the user he wants to send message .(not to mention shud

ber able to recieve messages)

I have gone through many lan messenger tutorials but din't find one which doesm't use any

server like ip messenger. Thanks in advance :)

Dani AI

Generated

A practical, single-EXE design is to have each client act as a tiny server: use UDP broadcasts for discovery/presence and TCP for the actual messaging. That mirrors ’s suggestion (UDP broadcast to find instances) and lets every instance advertise a reachable TCP listener so peers can connect directly. Use a well-known discovery port and a per-instance TCP listen port so the UI lists only other running instances on the same LAN. (learn.microsoft.com)

Discovery and presence maintenance: on startup broadcast a short packet such as DISCOVER;<username>;<tcpPort>;<instanceGuid> to the discovery port; listening clients add or update a peer entry and optionally reply with a unicast ACK. Do periodic heartbeats (e.g., every 20–60s) and remove peers after a configurable timeout (for example, 3 missed heartbeats) to handle crashes/power loss as warned. Treat UDP as best-effort—expect loss, reorder, or duplicates and design the discovery protocol to tolerate them. (learn.microsoft.com)

Connection and messaging: after discovery open a TCP connection (TcpClient/TcpListener) between the participants and exchange framed messages. Because TCP is a byte stream, use a framing scheme (a 4-byte length prefix is common) so reads are deterministic and multiple messages or partial reads are handled correctly. Example (sketch):

// send
var payload = Encoding.UTF8.GetBytes(text);
var len = BitConverter.GetBytes(payload.Length);
await stream.WriteAsync(len, 0, 4);
await stream.WriteAsync(payload, 0, payload.Length);

// receive helper (reads exactly count bytes or throws)
static async Task ReadExactAsync(Stream s, byte[] buf, int off, int count) { ... }

Implement async I/O, enforce max message size, and consider TLS (SslStream) for security. (learn.microsoft.com)

Troubleshooting notes: broadcast packets are limited to the local subnet and routers typically don’t forward them; firewalls can block UDP or incoming TCP so check firewall rules or test with it disabled. Multiple NICs/subnets require binding appropriately (or listening on IPAddress.Any). If network-wide discovery is needed and the infrastructure supports it, IP multicast is an alternative to per-subnet broadcast. Use Wireshark to watch discovery packets while iterating. (en.wikipedia.org)

Recommended Answers

All 2 Replies

I think in most cases like this the server is built into the client so that you don't need a seperate server app.

I would look at using UDP broadcasts for finding people who are online and then creating a client server link using TCP between the person initiatinag a chat and the recipient.

commented: great idea! The UDP broadcast locator mechanism is very handy +6

It is a little more difficult to determine and maintain a list of who is online without using a central server as all clients to need notify one another when they join or leave the chat. Due to unexpected application or power failures you can't always rely on an "Exit" method for the clients so you will also need to have the clients check one another to ensure they are online.

This can be done easily using the UDP broadcast mechanism privatevoid mentioned. I wanted to point that out so you had it in mind when designing your chat application.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.