>> However, this will only make sense, if there can be multiple sockets ready to be processed at the same time. As Daniel mentioned in another mail, since these sockets are just tcp streams, two sockets becoming ready at the same time might be unrealistic. If that is the case any extra effort spent on managing the sockets would be useless. Could any experts comment on this?
>

We need to get on the same page. In order to get a hard real time effect, you need operating system support, it has to provide you a real time TCP/IP stack. What I suggested can only work on the "best effort basis". It can only help you to avoid procesing a low priority jobs while high priority job is waiting for attention.

> I have similar doubts about the effectiveness of said method.
>
> The multi interface already does such sorting of timeouts per easy handle and that's the timeout value that is provided to the application. In a typical case, you will find that hardly any easy handle will have the same expiry time since we keep track of them internally with a millisecond resolution. But that's just a timeout value, in the end you will end up waiting for action on Y connections and at any given points N of them will have activity that require action.
>

Querying expiry times from each easy-multi pairs is necessary not to sleep too long.

> If you get N number of transfers that need attention after select() returns you can of course opt to handle to act on them in your own custom order but in order to make the order get any real significance you would have to NOT handle some low-prio handles in case there are high-prio handles having activity.
>

That is the whole point here. After returning from select, my code first checks whether high priority job needs action, if so action is provided and without doing any more work we are selecting again with the minimum expiry time. This goes on until select wakes up with no higher priority job needs immediate attention, then we process low priority job.

> You can probably achieve almost exactly that by just limiting the bandwidth use for the low-priority transfes so they will be slowed down (and not handled) if they run too fast.
>

Why not utilizing the whole bandwidth for low priority jobs when there is no or low density of high priority jobs?

Of course my design is going to decrease a bit performance (due to some extra function calls) and require more memory (due to requiring one multi interface for each easy interface), also it may forbid session reuse but I think it offers a better approximation to the problem decribed.

It is at the end a matter of politics, the best fit would need to be determined according to desired goal (user experience quality, more throughput, etc)
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-04-30