eCAP

Rate control in eCAP

Asked by Keith

I am try to construct a rate control function in eCAP.
Basically, it will intercept a connection, and send the data to the client in a specific rate. (for example, in a connection requesting a video, it will only send data slightly higher then the video bitrate, so no bandwidth is wasted if the user suddenly decide to stop watching the video)

When i collected the virgin data, I can save the data and serve it through abContent() at a specific rate.
But the problem is, after I collected all the virgin data, i will lost control of the program, so i cannot call noteAbContentAvailable() to ask squid to come and get my data.

Is there a way to get around this?
Is there a way i ask squid to call abContent() at another time?

Thank you for any help in advance.

Question information

Language:
English Edit question
Status:
Solved
For:
eCAP Edit question
Assignee:
No assignee Edit question
Solved by:
Keith
Solved:
Last query:
Last reply:
Revision history for this message
Alex Rousskov (rousskov) said : 		#1

eCAP API (as of v0.2.0) does not allow the adapter to proactively notify or call the host application -- the adapter must always be called by the host application. This limitation will be removed in future eCAP versions as we add adapter support for multithreading and concurrent I/O.

However, if you are dealing with Squid specifically, I believe it should keep coming back to your adapter transaction after the it consumes the already available adapted data: Adaptation::Ecap::XactionRep::noteMoreBodySpaceAvailable() calls
Adaptation::Ecap::XactionRep::moveAbContent() which calls libecap::adapter::Xaction::abContentShift(). This is not something I would rely on long-term, but it seems like it should solve your problem for now. Does it?

Revision history for this message
Keith (keith89926) said : 		#2

I tired to pass one byte at a time in abContent, and it seems to work, but this sounds too inefficient.

So I modified squid's source code, and solved this problem for the time being.

Thanks Alex Rousskov for your help.