Sobre porque o proxy pode atrapalhar ao invés de ajudar.

Bom dia colegas,

Embora tenha muitos anos de experiência com Sistemas Operacionais, principalmente GNU/Linux, não sou expert quando o assunto é redes, por isto, utilizei durante 2 anos um proxy Squid relativamente bem configurado, mas que não apresentava bons resultados. Já faz praticamente um ano que estou sem proxy algum em meu servidor.

Como faço controle de tráfego (download) por cliente na interface de saída, sempre tive a dúvida de como o Squid poderia controlar corretamente o seu próprio tráfego. Exemplo: Tenho um link de 2MB e vários clientes a 256K. Algum destes clientes que iniciem o download de uma ISO do Debian que não esteja em cache vai fazer com que o Squid inicie o download deste arquivo e entregue na velocidade de 256K ao cliente. Até aí tudo bem. Mas com que velocidade o Squid está baixando este arquivo para seu cache se não é feito nenhum tipo de controle de tráfego, aliás, nem teria como identificar o ISO que o Squid está baixando com o respectivo cliente na tentantiva de controlar tráfego, pois o IP do Proxy é que está fazendo todos os downloads dos clientes.

Eis a questão, se vários clientes, em uma rede com dezenas de clientes, talvez centenas de clientes, tudo que não existe no cache do Squid, este vai trazer sem qualquer tipo de controle, apenas vai entregá-los aos clientes e então o CBQ ou HTB que vai cuidar do controle do fluxo.

Existe alguma forma de fazer com que o Squid faça seus downloads obedecendo um controle de tráfego? O que quero dizer é totalmente diferente de delay_pools (acredito), pois não quero controlar a velocidade com que o Squid entrega o que já tem em cache ou que recém fez download, mas exatamente a velocidade com que o Squid traz cada coisa logo antes de entregar ao cliente.

Obrigado pela atenção e desculpem pelo longo email.

Aqui numa olhadela a algum tempo, o squid parerecia baixar na demanda do cliente, ou seja, se o cliente baixa a 256k ele segue essa velocidade; entretando os links gerenciados com Thundercache (v 2.1) baixam no talo.

Citação:

---

Postado originalmente por bjaraujo

Aqui numa olhadela a algum tempo, o squid parerecia baixar na demanda do cliente, ou seja, se o cliente baixa a 256k ele segue essa velocidade; entretando os links gerenciados com Thundercache (v 2.1) baixam no talo.

---

Interessante sua observação bjaraujo,

Que versão tens utilizado do Squid? À época usava Debian Etch e acredito que o Squid 2.5.

No caso, para quem não tem um link "sobrando" para o Thundercache, usá-lo tornaria o cenário pior nos momentos em que praticamente nada esteja vindo do cache correto?

amigo acho que vc esta errado, fiz teste marcando pacotes nas interfaces do meu squid e fazendo um download e observando o trafego nas interfaces foi exatamente igual, se aumentava a velocidade do cliente a do squid tb aumentava, penso que o squid baixa os arquivos como nosso navegador em partes para no final unir tudo, agora se vc utilizar aplicativos externos com seu squid como o thunder cache ai muda pois a velocidade de download será a do aplicativo, o que pode ser usado delay_pools para limitar o aplicativo mais não irar limitar o próprio squid .....

O que eu não consigo entender é como isto funciona e estou falando somente do squid, sem thundercache ou outra coisa. Exemplo:

cliente <-- 256k --> meu servidor <-- 2MB --> internet

Ou seja, meu servidor tem um link de 2MB com a internet e mesmo assim o squid vai ficar baixando a somente 256k? Como ele consegue "saber" disto?

Acredito até que o squid vai baixando conforme vai "entregando" ao cliente e como ele não consegue "entregar" a toda velocidade, vai atrasando o download. Mas até que ponto isto funciona tranquilo para diversar conexões é que não entendo. Eu tinha ganhos com o squid, o problema é que em horários de pico em que pouco era vindo do cache e a maioria era proveniente da internet, o squid tornava a navegação sensivelmente mais lenta. Até que um download, algo de alguns megabytes ele estabilizava em 256K, mas para navegação, com pequenos objetos, ele parecia esgoelar o link e atrasava tudo que não estivesse em cache.

Não consigo pensar em um forma de contornar este meu problema, que acredito que não seja somente meu, pois já li vários relatos neste sentido. Então recorro a vós.

Obrigado

Colega...Seu problema não é falta de link? Sinceramente, muitos não querem admitir mas o squid está ficando para traz por causa da ''dinamicidade'' da internet em relação a muitos arquivos.

Você acha que seu squid estava bem configurado, mas será se estava mesmo, ai de minha rede se não fosse o squid+thundercache.

Posta como estava o teu squid.conf ai para podermos analizar...

Citação:

---

Postado originalmente por flaviomreis

Interessante sua observação bjaraujo,

Que versão tens utilizado do Squid? À época usava Debian Etch e acredito que o Squid 2.5.

No caso, para quem não tem um link "sobrando" para o Thundercache, usá-lo tornaria o cenário pior nos momentos em que praticamente nada esteja vindo do cache correto?

---

Squid 2.7 com Ubuntu e Lenny, breve com Freebsd 7.2 (talvéz eu use o Lusca)

Citação:

---

Postado originalmente por flaviomreis

O que eu não consigo entender é como isto funciona e estou falando somente do squid, sem thundercache ou outra coisa. Exemplo:

cliente <-- 256k --> meu servidor <-- 2MB --> internet

Ou seja, meu servidor tem um link de 2MB com a internet e mesmo assim o squid vai ficar baixando a somente 256k? Como ele consegue "saber" disto?

Acredito até que o squid vai baixando conforme vai "entregando" ao cliente e como ele não consegue "entregar" a toda velocidade, vai atrasando o download. Mas até que ponto isto funciona tranquilo para diversar conexões é que não entendo. Eu tinha ganhos com o squid, o problema é que em horários de pico em que pouco era vindo do cache e a maioria era proveniente da internet, o squid tornava a navegação sensivelmente mais lenta. Até que um download, algo de alguns megabytes ele estabilizava em 256K, mas para navegação, com pequenos objetos, ele parecia esgoelar o link e atrasava tudo que não estivesse em cache.

Não consigo pensar em um forma de contornar este meu problema, que acredito que não seja somente meu, pois já li vários relatos neste sentido. Então recorro a vós.

Obrigado

---

Você tem que partir para QoS, então.

Citação:

---

Postado originalmente por Roberto21

Colega...Seu problema não é falta de link? Sinceramente, muitos não querem admitir mas o squid está ficando para traz por causa da ''dinamicidade'' da internet em relação a muitos arquivos.

Você acha que seu squid estava bem configurado, mas será se estava mesmo, ai de minha rede se não fosse o squid+thundercache.

Posta como estava o teu squid.conf ai para podermos analizar...

---

Foi comigo? Aqui uso o thuder e é ótimo! Mas ao menos aqui o bixin baixa no talo; outro dia observei lentidão na rede (foi a única vez que me lembro) e ao acessar o server havia + de 7 conexões ao window update de um único cliente, mas o problema durou pouco.
Aqui faço tudo num server usando duas interfaces estou para separar controle de tráfego do cache em dois servidores.
Tô doido para ver o thunder 3 pronto. :D

Citação:

---

Postado originalmente por bjaraujo

Você tem que partir para QoS, então.

---

Bom, vou explicar de novo. Tenho sim QoS, por isto descrevi o cliente com 256K. Os "problemas" realmente ocorrem próximos ao horário de pico, quando tenho pouco mais de 1,5M do link em uso.

O que quis ilustrar é que nestes momentos, em que tenho pouco mais de 1,5M do meu link de 2,0M em uso, a navegação com o squid habilitado como proxy transparente é sensivelmente pior que se neste mesmo momento eu desabilitar o squid.

Vou preparar um outro cenário com squid não transparente, ou seja, configurado diretamente na máquina do cliente e fazer alguns testes, então vou dar a opção ao cliente de usar ou não o proxy.

Certamente que isto vai diminuir e muito minha economia se grande parte dos clientes não aderirem ao proxy, pois não teria toda a quantidade de cache que da forma transparente.

Mas vamos lá.

PS: Certamente que se tivesse link "a vontade" nem usava squid, a não ser que fosse para usá-lo com ZpH.

Citação:

---

Postado originalmente por flaviomreis

O que eu não consigo entender é como isto funciona e estou falando somente do squid, sem thundercache ou outra coisa. Exemplo:

cliente <-- 256k --> meu servidor <-- 2MB --> internet

Ou seja, meu servidor tem um link de 2MB com a internet e mesmo assim o squid vai ficar baixando a somente 256k? Como ele consegue "saber" disto?

Acredito até que o squid vai baixando conforme vai "entregando" ao cliente e como ele não consegue "entregar" a toda velocidade, vai atrasando o download. Mas até que ponto isto funciona tranquilo para diversar conexões é que não entendo. Eu tinha ganhos com o squid, o problema é que em horários de pico em que pouco era vindo do cache e a maioria era proveniente da internet, o squid tornava a navegação sensivelmente mais lenta. Até que um download, algo de alguns megabytes ele estabilizava em 256K, mas para navegação, com pequenos objetos, ele parecia esgoelar o link e atrasava tudo que não estivesse em cache.

Não consigo pensar em um forma de contornar este meu problema, que acredito que não seja somente meu, pois já li vários relatos neste sentido. Então recorro a vós.

Obrigado

---

as vezes isso acontece pq a velocidade de leitura do seu objeto em cache é menor do que a de busca na própria internet, exemplo se o seu HD tem esta bem cheio com um cache enorme ele irar fica bem mais lento de se ler, a vezes o objeto tem apenas 100k mais será mais lento procurar ele no cache e entrega para o cliente do que buscar ele diretamente da internet. mesmo o hd sendo um de 10000 rotações, com mais de 100GB de cache ele será mais lento do que seu plano 256k direto, é um problemão que acho que somente pode ser resolvido com servidores em poderosos com RAID0 e etc .... isso varia muito e sempre quando mais poder melhor, mais sempre acho que vale a pena o servidor proxy, pq trás economia no link, ontem em um provedor em que presto suporte por exemplo o trafego do que não estava em cache foi 19GB e o do cache 4GB, foram 4GB de economia no link que foram usados para outros clientes. por esse motivo sempre mantenho meu cache em cerca de 50GB mesmo o hd tento 500GB, ele sempre fica excluindo os objetos mais velhos, acho que fica em torno de 3 dias em cache somente, mais já notei tb que as pessoas navegam geralmente nos sites que estão em cache em pouco tempo, poucos acessam sites que já sairam do cache após vários dias, sobre a velocidade o thunder não faz como o squid, ele baixa na velocidade maxima mesmo .....

Citação:

---

Postado originalmente por pedrovigia

as vezes isso acontece pq a velocidade de leitura do seu objeto em cache é menor do que a de busca na própria internet, exemplo se o seu HD tem esta bem cheio com um cache enorme ele irar fica bem mais lento de se ler, a vezes o objeto tem apenas 100k mais será mais lento procurar ele no cache e entrega para o cliente do que buscar ele diretamente da internet. mesmo o hd sendo um de 10000 rotações, com mais de 100GB de cache ele será mais lento do que seu plano 256k direto, é um problemão que acho que somente pode ser resolvido com servidores em poderosos com RAID0 e etc .... isso varia muito e sempre quando mais poder melhor, mais sempre acho que vale a pena o servidor proxy, pq trás economia no link, ontem em um provedor em que presto suporte por exemplo o trafego do que não estava em cache foi 19GB e o do cache 4GB, foram 4GB de economia no link que foram usados para outros clientes. por esse motivo sempre mantenho meu cache em cerca de 50GB mesmo o hd tento 500GB, ele sempre fica excluindo os objetos mais velhos, acho que fica em torno de 3 dias em cache somente, mais já notei tb que as pessoas navegam geralmente nos sites que estão em cache em pouco tempo, poucos acessam sites que já sairam do cache após vários dias, sobre a velocidade o thunder não faz como o squid, ele baixa na velocidade maxima mesmo .....

---

Mas eu estou falando é justamente o contrário, quando o squid não tem em cache e tem que buscar na internet, nesta hora, quando tenho 1,5M de meus 2,0M em uso, o squid gera latência, mesmo não buscando do cache, ou seja, ele não faz leitura alguma no disco porque não está em cache.

O que PODE ser é que antes de entregar ao cliente ele precisa localizar se existe em cache e como são diversos pequenos objetos, então significaria uma demora até procurar e não encontrar. Mas aí fica a pergunta, porque isto não gerou carga de CPU? Pois não notava quase nada de uso para as I/O?

Citação:

---

Postado originalmente por pedrovigia

...mais sempre acho que vale a pena o servidor proxy, pq trás economia no link, ontem em um provedor em que presto suporte por exemplo o trafego do que não estava em cache foi 19GB e o do cache 4GB, foram 4GB de economia no link que foram usados para outros clientes. por esse motivo sempre mantenho meu cache em cerca de 50GB mesmo o hd tento 500GB, ele sempre fica excluindo os objetos mais velhos, acho que fica em torno de 3 dias em cache somente, mais já notei tb que as pessoas navegam geralmente nos sites que estão em cache em pouco tempo, poucos acessam sites que já sairam do cache após vários dias, sobre a velocidade o thunder não faz como o squid, ele baixa na velocidade maxima mesmo .....

---

20% de economina já é algo apreciável.

Ontem estava conversando com uma pessoa sobre o tempo que os arquivos ficam em cache.
Não teria como excluir não por tempo de permanencia, mas por número de acessos?

Pode acontecer de algo ficar armazenado, e não ser requisitado por mais ninguém. E está ali ocupando espaço. Se não fosse requisitado por um determinado tempo ele iria para o inicio da fila de exclusão. E aqueles que estivessem sendo requisitados mais frequentemente permaneceriam, independente do tempo.

É possível isso, Pedro?

Amigo,
pelo o que vi voce não conhece bem o assunto squid, ou pelo menos nao chegou a ler o documentação oficial do mesmo,
como contribuição eis aqui algumas informações:

a) o squid não faz donwload ou up-load de arquivos, ele apenas faz as requisiçoes em nome das máquinas que estão atraz dele, filtrando tudo o que passa por ele aplicando as políticas de acesso/seguranças e finalmente gravando uma cópia do que é baixado e das solicitaçoes para que futuramente não seja necessario baixar o mesmo aquivo da net novamente e pra que se possa fazer os relatorios de acessos estatisticas os quais podem ser interpetados por outra aplicação como por exemplo o SARG ou similar.

b) Quanto ao controle de banda. Se o servidor proxy/squid e os shapers ( HTB/CBQ) estiverem instalados na mesma maquina, realmente existe muita confusão a esse respeito, pois se vc direciona as requiisições para o squid é óbvio que os controladores de banda não irão funcionar, sobretudo o up-load, pois nesse caso é necessário marcar préviamente os pacotes via iptables e joga-los nas nas classes corretas e so depois direcionaos ao squid para que se tenha algum tipo de controle, mas mesmo assim o up-load não irá funcionar 100%.

c) existe ha possibilidade de controlar banda também através do proprio squid, com as chamadas delay pools, que eu particulamente acho extremamente eficiente, basta um pouco de prática em configuarar as acl(s) dst/src (destino/origem).

d) agora se o proxy está em uma máquina e em outra está o gateway com um controlador de sua preferencia HTB ou CBQ, eu particulamente prefeiro fazer na unha mesmo usando o proprio TC, nao importa se vc usa linux o proprio Mk o controle de banda irá funcionar perfeitamente, basta que para isso os pacotes seja devidamente marcados e direcionados para as classe corretas.

como sugestão é sempre bom dar uma pesquisada nos assuntos referente iptables,iproure, tc,squid/acls

Citação:

---

Postado originalmente por fenixprovedor

Amigo,
pelo o que vi voce não conhece bem o assunto squid, ou pelo menos nao chegou a ler o documentação oficial do mesmo,
como contribuição eis aqui algumas informações:

a) o squid não faz donwload ou up-load de arquivos, ele apenas faz as requisiçoes em nome das máquinas que estão atraz dele, filtrando tudo o que passa por ele aplicando as políticas de acesso/seguranças e finalmente gravando uma cópia do que é baixado e das solicitaçoes para que futuramente não seja necessario baixar o mesmo aquivo da net novamente e pra que se possa fazer os relatorios de acessos estatisticas os quais podem ser interpetados por outra aplicação como por exemplo o SARG ou similar.

b) Quanto ao controle de banda. Se o servidor proxy/squid e os shapers ( HTB/CBQ) estiverem instalados na mesma maquina, realmente existe muita confusão a esse respeito, pois se vc direciona as requiisições para o squid é óbvio que os controladores de banda não irão funcionar, sobretudo o up-load, pois nesse caso é necessário marcar préviamente os pacotes via iptables e joga-los nas nas classes corretas e so depois direcionaos ao squid para que se tenha algum tipo de controle, mas mesmo assim o up-load não irá funcionar 100%.

c) existe ha possibilidade de controlar banda também através do proprio squid, com as chamadas delay pools, que eu particulamente acho extremamente eficiente, basta um pouco de prática em configuarar as acl(s) dst/src (destino/origem).

d) agora se o proxy está em uma máquina e em outra está o gateway com um controlador de sua preferencia HTB ou CBQ, eu particulamente prefeiro fazer na unha mesmo usando o proprio TC, nao importa se vc usa linux o proprio Mk o controle de banda irá funcionar perfeitamente, basta que para isso os pacotes seja devidamente marcados e direcionados para as classe corretas.

como sugestão é sempre bom dar uma pesquisada nos assuntos referente iptables,iproure, tc,squid/acls

---

Aqui foi falado tudo. O Squid apenas faz uma cópia, ele não baixa nada diferente do que foi feito na estação. Você deve verificar se tem algo fazendo os downloads, tipo o Thunder mesmo. Isso aconteceu comigo aqui quando usava VideoCache. Só para constar uso Squis 2.6 e 2.7 a 4 anos no provedor com Htb e cache full, tenho rendimentos abusurdo de link aqui.

Citação:

---

Postado originalmente por 1929

20% de economina já é algo apreciável.

Ontem estava conversando com uma pessoa sobre o tempo que os arquivos ficam em cache.
Não teria como excluir não por tempo de permanencia, mas por número de acessos?

Pode acontecer de algo ficar armazenado, e não ser requisitado por mais ninguém. E está ali ocupando espaço. Se não fosse requisitado por um determinado tempo ele iria para o inicio da fila de exclusão. E aqueles que estivessem sendo requisitados mais frequentemente permaneceriam, independente do tempo.

É possível isso, Pedro?

---

não sei se é possivel essa configuração, mais irei pesquisa, será otimo se for possivel fazer ....

Citação:

---

Postado originalmente por Josue Guedes

Aqui foi falado tudo. O Squid apenas faz uma cópia, ele não baixa nada diferente do que foi feito na estação. Você deve verificar se tem algo fazendo os downloads, tipo o Thunder mesmo. Isso aconteceu comigo aqui quando usava VideoCache. Só para constar uso Squis 2.6 e 2.7 a 4 anos no provedor com Htb e cache full, tenho rendimentos abusurdo de link aqui.

---

isso é verdade proxy não é somente para cache, alguns como o analogx e o ziproxy não o fazem ....

Bom, acredito que eu não tenha me feito entender plenamente até agora, pois vou continuar tentando. Independente de o Squid estar ou não na mesma máquina que faço shape/traffic control, tenho que direcionar todas as requisições à porta 80 para ele, então ele mesmo faz a requisição ao destino, sendo assim quem está recebendo os dados do destino é o Squid e não o cliente. Ah sim! Mas o Squid repassa direto ao cliente, tudo bem, mas é como se o Squid tivesse feito o download também, até por isto ele consegue gravar em disco o que ainda não possui.

Dito isto agora acredito que eu tenha entendido algo que nem era pra ser complicado e eu já deveria ter entendido antes.

Exemplo. Meu cliente está baixando um ISO do Debian a 256k e meu servidor não tem proxy. Tranquilo, meu servidor recebe os pacotes e repassa ao cliente ao limite estabelecido, ou seja, 256k. Não sei exatamente qual o tamanho dos pacotes e nem qual a quantidade exata deles, acredito que isto seja variável, então o servidor vai equilibrando o recebimento conforme entrega ao cliente.

Já se meu servidor tem proxy, acredito que a sistemática seja a mesma, ou seja, o Squid faz o último papel, de fazer a solicitação e devolver ao servidor para este entregar ao cliente.

Sendo assim, acredito que o problema de sensível demora que o Squid tenha apresentado em minha estrutura deva-se ao meu hardware não ter a performance exigida para não causar latências perceptíveis.

Meu servidor, na época em que tinha o Squid habilitado, era um Atlhon 64 3200+ com 512M de RAM e disco rígido de 80GB de 7200RPM, onde tinha definido 30GB para cache (há dois anos atrás muito pouco youtube ou outros vídeos ocupavam o link), para um link de 2M e 150clientes de 1288 a 256k.

Como pretendo utilizar novamente Squid (por causa do ZpH, ainda não sei se vou utilizar algo como o Thundercache por não saber como evitar que este não balanceie as requisições), adquiri um novo servidor com Processor Atlhon II 7750 de 2,7GHz, 4GB de RAM e 320GB de HD (pretendo colocar outro HD de 320G e fazer RAID 0 para tentar agilizar I/O), isto para um dois links de 2M e 200 clientes em média a 300k).

Dentro de algumas dias já terei-o pronto para por em produção e então relato aos amigos a experiência.

discursão a parte, vamos a solução do seu problema, e para isso iremos usar o proprio squid para se uma idéia da versatilidade de expecional proxy/cache que modesta a parte acreido domino o bastante paras as minhas necessidades.

primeira solução o recurso delay_pools


#controle de banda
acl extensoes url_regex -i .zip .exe .mp3 .gz .rar .avi .wmv .mpeg .mpg .gt .ram .rm .rmj .iso .raw .wav .mov .flv

acl rede1 src "/etc/squid/rede1"
acl estacao1 src "/etc/squid/estacao1"

#aqui se informa a quantidade de dalays seria o equivalente as classe do HTB ou CBQ
#nosso exemplo vamos usar 4 para fins didatiicos

delay_pools 4

#youtube bandlimit
acl downsites url_regex youtube
delay_class 1 1
delay_access 1 allow downsites
delay_parameters 1 20000/20000 # 20000 x 8/1024 = 156,25kbps
#nesse casso todos os acessos ao dominio do youtube estaramo limitadas a 156,25kbps


delay_class 2 3
delay_parameters 2 -1/-1 7000/7000 7000/7000 # 7000*8/1024= 54,60 kbps
delay_access 2 allow rede1
#ja no segundo exemplo os ips contantes da rede1 estarao limitado a 54,60 kbps

delay_class 3 3
delay_parameters 3 -1/-1 -1/-1 7000/7000
delay_access 2 allow estacao1
# no terceiiro exemplo os ips contantes da classe estação1 estarao limitado a 54,60 kbps

delay_class 3 4
delay_parameters 4 -1/-1 -1/-1 7000/7000
delay_access 4 allow extensoes
# nesteo exemplo apenas os arquivos coms a extenções .exe .zip .iso .... estarao limitado a 54,60 kbps

delay_access 3 allow cliente2

#obs crie os arquivos rede1 e estacao1, dentro do diretorio /etc/squid, de permissao de leitura e escrita
e dentro dele coloque os ips que serao controlados.

ok
em caso de duvida é so postar que estou aqui para ajudar.

Citação:

---

Postado originalmente por bjaraujo

Aqui numa olhadela a algum tempo, o squid parerecia baixar na demanda do cliente, ou seja, se o cliente baixa a 256k ele segue essa velocidade; entretando os links gerenciados com Thundercache (v 2.1) baixam no talo.

---

Aki eu não deixo meu thunder mandando a full,... ai os arquivos que estao no proxy (thunder) vem na velocidade contratada pelo cliente.Quando o thunder baixa pela primeira vez,ele Puxa a cravados 680kbps.Por isso deixo um link de 8MB destinado a receber todos os plugins usados pelo thunder.... Fazendo assim,numca tive problemas de gargalo de link por causa do thunder...

Outro detalhe,uso o squid para ter uma otima navegação...os arquivos cacheados pelo mesmo, ficam setados em no max 3MB.... assim ele trabalha mais com paginas mesmo e arquivos muito pequenos... outro detalhe, uso HD em Raid0 de 32MB de buffer,causando assim um cache grande de paginas nesses 32MB de buffer,ocasionando assim uma grande velocidade na abertura das paginas... Outra coisa é que alem de marcar os pacotes do squid no mangle,deixo setado 3MB de Down e 3MB de UP no queue tree,pode nao parecer,mas faz as paginas cacheadas voar... Nos clientes uso apenas AP (APRouter6.1) e faço um pre-controle de banda nos radios,seto no max 1MB de down e 128k de up... Assim as requisições chegam pré-filtradas até meu servidor....