Click here to Skip to main content
15,791,567 members
Please Sign up or sign in to vote.
4.67/5 (2 votes)
See more:
I am developing a video chat site.

1. Each clients sends her/his capturing video using socket to server.
2. And the server forward the received data to the rest of clients except the sender.
3. Then each clients who receive the data show it through the image viewer.

each clients send their images on single port (ex:4524).
The receiver should identify each packets from the port and let the packets form same client match one of image viewers.

Is it possible to identify each packets from a port whether it is from same client ?

Or any other idea that shows video imgaes from multiple clients ?
Updated 9-Mar-11 19:47pm

1 solution

Maybe I did not completely understand your idea, but I feel you're confusing something. Anyway, I have a clear idea how to work with multiple clients to identify them properly.

Generally, just one IP port is quite enough. You seemingly confirm it. Then, the port is the attribute of the service side, not client's. A client only uses the known port of the service whem trying to connect. If so, what does it mean "to identify each packets from a port".

However, your problem is easy to solve. The unique identification at the service side is the remote socket of the client, that is, a socket as an object of the service code which represent the remote socket of the client.

You can use TPC, hence sessions. A remote socket represents a client's socket on the service side as long as both sides keep the connection alive.

You can use socket level, but with .NET I would prefer a bit higher level: using System.Net.Sockets.TcpListener on service side and System.Net.Sockets.TcpClient on client side.

The schema of the operation should be like this: on the service side, you need two separate threads: one accepts new client connections (let's call it listening thread), another one writes and reads data to/from NetworkStream following some application-level protocol you develop in cycle with all available remote (client's) sockets (let's call it communication thread). Those sockets are created in the the communication thread which calls the method System.Net.Sockets.TcpListener.AcceptTcpClient in infinite cycle. This method is blocking, so the thread will be in wait state most of the time. This method returns the object representing a newly created client socket on the service side (of the same type: TcpClient). Now, you should support collection of such TcpClient instances (more exactly, some data items each including a reference to such instance, see belo); this collection is used by both thread. The item type of this collection should associate some client-specific data (I don't know if you want to use authentication, but — whatever involved). This is association is the client identity you need. Don't forget to use appropriate locking primitives to make collection operation thread-safe.

In case a client breaks connection by whatever reason, your communication thread will throw exception. This exception should be caught; and the exception handler used to remove the client record from the collection. In this way, you don't need any special ceremony for graceful disconnection: everything will work, even the power off on the client machine. This is my idea: graceful connections is the invention in vane: some disconnection will be non-graceful anyway (all kind of network failures), so why bothering?

Some extra information: for threads I recommend to use a thread wrapper; the sample code and explanation you will find here: How to pass ref parameter to the thread[^].

You may want to have additional thread(s) for "busyness logic" and inter-thread communication; consider blocking queue and inter-thread invocation I offer in my Tips/Tricks article: Simple Blocking Queue for Thread Communication and Inter-thread Invocation[^].

Share this answer
thatraja 25-Dec-11 1:03am    
Nice, 5!
Sergey Alexandrovich Kryukov 25-Dec-11 1:19am    
Thank you, Raja.
Oleksandr Kulchytskyi 1-Jun-12 15:20pm    
Great explanation =) I see you are very comfortable in server\client architecture, especially in net sphere.
It's a big pleasure to read you posts and solutions =)
Sergey Alexandrovich Kryukov 20-Jun-12 16:52pm    
Thank you very much, Oleksansr.
I actually usually criticize pure client-server model as it is very limited, does not offer inversion of control and push technology. All pull-only approaches are always bad:
The freedom of custom networking allows for much superior architectures, such as the ones adding publisher-subscriber model, which is quite simple and actually known for many years...
hatinh162 30-Jul-14 22:56pm    
thank you for the post. I understand your idea on the server but when I create TcpClient on client pc to accept the socket, I get error : 10060 : "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond". I searched more article but no fix problem. do you have idea for client pc? please help me.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900