Single socket, more than one socket, multithreading?

[Chirieac]

Hello! I want to make an app (for personal use) with this functionality (I'm using MFC):
1. Send the screen of one computer to another;
2. Send only a window from one computer to another (using PrintWindow function);
3. Capture the webcam and send it to, again, another computer.
(all 3 in the same time)

I think there are 3 solution to do this:
1. Use just one socket: record the screen, window and webcam in one thread and send it through one socket (problem: must wait to receive the screen in order to get the webcam: "received data: ahh... the screen, ok... another data... the screen again?" what I want to say is that if the screen manage to send itself more than 2 frames before the webcam I must wait to the screen).
2. Use multiple socket?! I declare 3 socket variables: one for each connection (screen, window, webcam)? This means I must listen on 3 different ports on the server? (I don't like more than one port).
3. Multithreading? Ok... use 3 different threads: one (the main) to capture the desktop and send it over the net, one for window and one for webcam. But, using the same socket to send data or diferent socket?

One question: is multithreading usefull on the server? The user will not interact with the server more than make him listen. I've read that multithreading is helpfull when you want to make your UI more responsive. (should I capture all 3 things in one thread?).
What about the client side? Should I have 3 separate thread?

One way:
On the client side I declare 3 socket variables. The main socket will connect the app and will handle the receiving of data from the screen; the other 2: the window and the webcam. No need for multithreading, right? The client will not make any intense calculation: just receive and display and I think there is no need for multithreading.
But, how do I connect with 3 socket on the server with only one port? I think I must create a main socket on the server that will listen for connections and will handle screen capture. When the client want to get data from the webcam (or a window) the app will connect to the server with another socket and the server will create a separate thread for this request and another socket for connection.
But how I do this? How I know on the server which kind of thread should I create: is for a webcam or window capture? How I know that the request is not from another client. All I have is the OnAccept event.

I hope you understand what I've said. Please help me! My time to do this project is running out!
Bye!

[henky@nok.co.id]

What you need to concern are:

1. Captured image size. In some cases you may need data compression
technology.

2. To transfer data as fast as possible to destination, you may concern to
use multiple sockets using multithreading by splitting image data into
several split data. With this technique you can send data as parallel.

Henky

[Chirieac]

Thanks henky for your reply!

If I'll use multiple sockets with multithreading I will receive data faster?
Here's a test of mine (using localhost):

At first I've send it 20mb through one socket and then 5mb through the same socket: time 12sec.
Then I've used 4 apps (to simulate multithreading): app A listening on port 4000 and app B on port 4001; with app X I've connected to app A and app Y to app B.

After that I've send it from app A 20mb and then from app B 5mb after 1 sec.

Result: of course I've received the 5mb first and then those 20mb, but still in 12 sec.
So, is my test right?

[henky@nok.co.id]

Not exactly right.

1. localhost can't simulate real networking world since it works on memory.
2. 4 apps will not have same performance as 4 threads.

What i meant, you need to split your data first.
ie: 200 MB split into 50 MB, then trasfer them using 4 threads.

Some of download accelerator softwares use this technique.

Henky

[Chirieac]

Thanks for your quick reply!

What I want is this:
on some intervals of time I want to send different data like images, sound or file transfer. So, is better to send this data through different sockets on different thread?

[Chirieac]

I ask because I don't know multithreading and before I start learning I want to know if I need it first.

[Chirieac]

The bottom line is: I will receive data faster if I'll send it through multiple sockets with multithreading?
If yes, what about multiple sockets without multithreading?

[Chirieac]

I've search it the answer in google and no luck. I read right now the book Network Programming for Windows, second edition. Maybe I'll find in there any answer for advantages in using multiple socket, when and how to use it.

[henky@nok.co.id]

I've search it the answer in google and no luck. I read right now the book Network Programming for Windows, second edition. Maybe I'll find in there any answer for advantages in using multiple socket, when and how to use it.
Sorry for my late reply. I am living in Japan timezone.

In order to realize faster transmission, you must use multithread with
multiple socket. It won't be useful if using multiple socket but in single
thread, cause it will work in sequential order.

[Chirieac]

Thanks again henky!

One final question: Do I need to listen on multiple ports?

It will work like this: server listening on one port; client is connecting with 2 sockets to the server; the server on accept creates 2 threads with 2 sockets, one for each connection?

Thanks again, Bye!

[henky@nok.co.id]

Thanks again henky!

One final question: Do I need to listen on multiple ports?

It will work like this: server listening on one port; client is connecting with 2 sockets to the server; the server on accept creates 2 threads with 2 sockets, one for each connection?

Thanks again, Bye!
You're welcome.

No. You don't need to listen on multiple ports.

Regards,
Henky

[TheCPUWizard]

In order to realize faster transmission, you must use multithread with multiple socket. It won't be useful if using multiple socket but in single thread, cause it will work in sequential order.

This is COMPLETELY UNTRUE.

A single threaded application using IO Completion ports will have equivilant performance to a multi-threaded application.

Also for transmission, everything will STILL be serialized through the network adapter (you can only be physically transmitting one bit at a time), the improvement with multiple sockets will have a fairly low upper bound. The primary benefit with multiple streams is the interleaving of the ACK/NAK process that happens below the covers.

[Chirieac]

Thanks TheCPUWizard for your reply! So, even I send different data in the same time through multiple sockets I will still receive the data in the same amount of time if I will send it through one socket?

[TheCPUWizard]

Thanks TheCPUWizard for your reply! So, even I send different data in the same time through multiple sockets I will still receive the data in the same amount of time if I will send it through one socket?

Look at the actual sequence...

1) You get data from "somewhere"
2) You submit the data to the operating system for Transmission
3) The NIC (hardware) get data from the OS and transits when the Wire is Free.
4) The NIC tells the OS that the Transmission is Complete
5) The OS tells your application that transmission is complete.

Step #3 is the place where things become sequential (for the real tech heads it is a sub-step of #3).

The goal is to keep step #3 busy as close to 100% as possible.

A multithreaded approach has (somewhat) independant threads all pushing data at the NIC. These threads will each block while the NIC is busy, but will wake quickly when it becomes available. However you have no control over which one will wake up, and the data it will transmit has already been pre-determined.

An IO completion port allows you do directly control what wil get transmitted next.

Consider Video being used like a survalaince camera. If everything is going "Smooth" it would be good to get a full 60 frames of video per second. However if things temporarily fall behind, then it may be acceptible to drop frames rather than queue them up in the attempt to "Catch up".

[Chirieac]

Thanks again! I will read about IO completion ports...
The idea is this: if i send data through one socket the data will be put sequential to the operating system, even if I call send one after another,
since if i send it through multiple sockets (with IO completion ports or multithreading) the data will be put in to the operating system in parallel?
Bye!

[TheCPUWizard]

That is correct. You will parallelize the processing through the operating system, but NOT through the hardware.

[Chirieac]

Thanks! I get it now... Bye!

[henky@nok.co.id]

This is COMPLETELY UNTRUE.

A single threaded application using IO Completion ports will have equivilant performance to a multi-threaded application.

This is COMPLETELY UNTRUE.
Look at next red-colored line and consider also about preemptive scheduling.
Also for transmission, everything will STILL be serialized through the network adapter (you can only be physically transmitting one bit at a time), the improvement with multiple sockets will have a fairly low upper bound. The primary benefit with multiple streams is the interleaving of the ACK/NAK process that happens below the covers.

[TheCPUWizard]

Henky,

I have only been doing network analysis of etherrnet based systems for about 23 years.....

It does APPEAR that there is a contratiction in the items you quoted, but there is not, if you look at the total network picture. The actual end-2-end total transfer time will be so close that the random variations caused by CSMA/CD will actually overlap the differential rendering it meanless.

Remember that we are talking about comparing a long running volume of data that is effectively traveling from point-2-point, and the issue is total throughput over time.

Note that in the first I am NOT saying to use a single Socket, but that a single thread can effectively serice many sockets. You still get the full benefit of the overlapping of ACK/NAK.

With multiple threads there are (by definition) Context switches which take time. With Completion ports these are minimized.

The actual calculation becomes how long is the single thread busy with one completion request before it can service the second. If this time is long enough that the NIC gets starved for data (resulting in a gap in the transmission), then it has meaning. With the current capabilities of NICs, and the buffering that is inherent in the OS, this is VERY rarely the case.

This is actually very easy to test with a simple network analyzer that examines the timing of the individual packets, and the duty cycle of carrier sense (remember that transmitters are REQUIRED to put gaps into the stream to avoid clogging the network.

Now if you really what to get the last bit of performance out, then the best bet is to split the transmissions over multiple NIC's that are connected to different internet access points (assuming you local connection is the slow point of the chain).

[henky@nok.co.id]

I just never compare between multithread with multiple socket and
single thread with multiple I/O completion port socket.
I have no word to say no. You are absolutely right. Sorry made you impatient:).

[TheCPUWizard]

I just never compare between multithread with multiple socket and
single thread with multiple I/O completion port socket.
I have no word to say no. You are absolutely right. Sorry made you impatient:).

Not to worry. Usually if someone questions one of my posts, it means I rushed the answer and did not fully explain myself.... :wave: :wave: :wave: :wave: