[squid-users] Any way to cause 512 byte alignment of data passed to ECAP?

Alex Rousskov rousskov at measurement-factory.com
Wed Jan 9 18:22:09 UTC 2019


On 1/9/19 9:39 AM, Russel McDonald wrote:

> 1.       Is there any way to configure squid to align the data passed to
> ECAP to occur on 512 byte boundaries, of course allowing for any ending
> partial size? 

No, it is not possible to force Squid to align HTTP message data made
available to adaptation services. If you have to do something like that,
you might be able to shape the incoming TCP data into properly sized
packets before Squid reads them, but even if you are successful at that
difficult task, Squid may aggregate or split TCP payloads for various
reasons.


> If that is not a current capability then is that an acceptable
> feature someone could join and contribute?

I do not think so: In eCAP, it is the adapter that pulls message body
data from the host application! The host application (in your case
Squid) does not push data into the adapter. Thus, an adapter can pull as
much or as little as it wants, observing whatever "alignment" it needs.


> 2.       When streaming a file, say playing a song (.m4a file), and
> scroll bar is jumped to the end of the song, is there any way that the
> ECAP callbacks specify where at in the file the stream restarted from?

No, not directly: eCAP does not know anything about files, songs, and
scroll bars. It works at the lower HTTP level while you are asking about
higher level metadata that would be specific to the playback
protocol/method being used on top of HTTP.


> Dumping and looking at the chunk contents in method
> noteVbContentAvailable  I don’t see any HTML that indicates any
> offset/position/range. And in start enumerating the HTTP header entries
> I don’t see any such either (adapted->header().visitEach(*visitor);).

*If* the plugin/code in the client browser has requested something
special after the "scroll bar is jumped to the end of the song" event,
then that special request will be reflected in HTTP request headers
and/or body. It could be the request URL itself, the Range header field,
some custom request header, or even something inside a POST request body.

All those things _can_ be analyzed by an eCAP adapter code, using
existing eCAP APIs, of course. It is adapter responsibility to map those
HTTP concepts to playback position or any similar applicaction-specific
info.


HTH,

Alex.



More information about the squid-users mailing list