ASM51

Prezados

Tenho uma WS (Workstation) que precisa atualizar N WS via rede.
Atualizar = Transferir um monte de arquivos.

1) Nao tenho banco de dados em rede portanto negativo usar essa prerrogativa.

Processo:
Uma app gera os arquivos na WS Central.
Esses arquivos deverao ser enviados para WS espalhadas na rede (que tem uma app "A" rodando).
"A" so tem a funcao de pegar os arquivos e por num buraco qq.
Depois de transferir os arquivos pela rede (sem mapear diretorios nas WS espalhadas)....
A WS central vai mandar um comando pra outra aplicacao "B"rodando nas WS espalhadas...tipo ATUALIZE TAG= xxxxxx , onde xxxxx seria por exemplo o nome do diretorio onde estariam armazenados os arquivos

O problema é que um arquivo por exemplo pode ter sei la 1 MB ....
e pode ter N arquivos pra transferir.

E ae ? Como fazer um FILE TRANSFER pra rodar numa LAN ?
Delphi eh claro.....

"A" poderia ser uma app rodando em nivel de servico sem problema
grato se derem alguma ideia...ou outra topologia....

A aplicacao na WS central so roda nessa hora e pode rodar de qq lugar, portanto nada das WS clientes apontarem para algum lugar....s WS conhece os IPs das clientes, o contrario nao.

E AE ?

Xau.

bom, supondo que:
1) não pode usar nada fora do Delphi e nem pode supor versão do windows
2) o WS central tem IP dinâmico
3) todas as máquinas estão em uma mesma rede local, sem precisar passar por nenhum proxy, gateway ou qualquer coisa do tipo, ou seja, dá pra usar broadcast
4) os WS clientes ficam 24 horas rodando, só o WS central que não
5) a versão do delphi é Turbo Delphi Explorer, e não pode usar nenhum componente "extra", e não pode usar os componentes Indy ou outro de servidor de ftp ou coisa parecida

neste caso eu acho que tu tá ferrado e, se fosse eu, faria no braço mesmo, utilizando UDP para mensagens entre os aplicativos A e B e usando TCP para transmitir arquivos entre A e B.

Aplicativo B, quando inicializado, fica escutando mensagens em uma porta específica (UDP) por mensagens do A. Essa porta deve ser fixa para todos os apps B.

A, quando gerar atualizações, faria o seguinte:
1- cria um socket que fica em listen em uma porta vaga qualquer usando TCP,
2- manda uma mensagem em broadcast para os Bs usando UDP na porta fixa, esperando uma resposta dos Bs, para montar a lista de clientes, caso A não saiba exatamente a lista de clientes.
3- de posse da lista de clientes, A começa a atualizar cada cliente da lista.

Para atualizar cada cliente da lista, A faria:
1- pega o endereço do cliente da lista. A porta UDP usada é fixa.
2- manda uma mensagem UDP direta para o ip do cliente, informando a porta TCP do "servidor" a ser utilizada.
3- o B selecionado conecta-se ao IP do A usando TCP, no IP da mensagem recebida do A e na porta informada na mensagem.
4- o A aceita a conexão TCP, começa o protocolo de atualização. A manda para B via TCP os arquivos na seguinte forma: transmite o tamanho da string do nome do arquivo, transmite o nome do arquivo, transmite o tamanho do arquivo e depois todos os bytes do arquivo. Caso tenha mais arquivos, A começa de novo, transmitindo o tamanho da string do nome de arquivo, nome do arquivo, tamanho do arquivo e bytes... até cabar os arquivos. Cabou os arquivos, A desconecta o B, e pega o próximo cliente da lista pra atualizar, voltando pro passo 1.

Obviamente tem que ver os "time-outs", levar em consideração que o UDP não é confiável (o TCP é), se existe a necessidade de gerenciar versões nos Bs, como por exemplo, se um cliente pode não estar online em uma ou mais atualizações, ficando com versão muito mais antiga.

Também pode-se otimizar, como por exemplo, em vez de atualizar um por um, o A pode tentar atualizar "todos os Bs" de uma vez, mandando mensagem em broadcast e fazendo um pool de conexões TCP.

Outra idéia seria usar algo um pouco mais alto nível como CORBA ou DCOM.

Caso o WS central possa compartilhar uma pasta, pode sumir com a parte de TCP, o A enviaria somente o endereço no formato "\\computador\pasta compartilhada com os arquivos" e os Bs receberiam isso por UDP, poderiam copiar os arquivo via serviço do windows (nem precisaria mapear unidade pela rede), e fariam o update.

ok
animador! :p

Bom dia

Decidi pela solucao do FTP server
É mais simples...de fazer
Vou tentar primeiro com o FileZilla Server ....
e através de um componente FTP client fazer um GET na parada...
creio que vá ser suficiente para fazer o bagulho

é, com o ftp fica muito mais fácil, só tem o problema do server ftp ter que ficar em um endereço lógico que seja fixo.

O IP é fixo, pois o sistema vai rodar numa LAN.

Basicamente há uma app que gera os dados e faz um upload FTP no server. O processo de upload segue uma regra básica. O nome do diretório a ser criado tem tudo a ver com a data e hora do server.

Aplicação Servidora de Arquivos
{Raiz}
20070915204732, por exemplo
é um diretório criado em (AAAAMMDDHHNNSS) conforme a hora em que está sendo executado o processo, e todos os arquivos são colocados nele.

Dai no {raiz } depois de transferir tudo...passo a gerar os tags de atualizacao..
Crio N=40 arquivos com nomes ID001.DAT ...até ID040.DAT
Dentro desses arquivos tem :

Linha 1: O nome do (ultimo) diretório criado.
Demais linhas...a lista de arquivos que tem dentro deste diretório.

Fim de processo.

Aplicação Cliente
A aplicação cliente tem um timer que roda de 1 em 1 hora, para tentar fazer a conexão no server. 1 hora foi escolhida ao acaso pois não é uma tarefa que exija tanta necessidade.

Cliente conecta e procura no raiz o seu tag IDNNN.DAT...baixa o arquivo e ve que nele tem um diretorio e novos arquivos pra baixar. Baixa os arquivos todos e só depois de fazer checkup de tudo é que vai lá e apaga o id dele. Assim na próxima iteração (depois de 1 hora) não vai ver nada e fica na paz....

Problemas inerentes, prá pensar....apesar da baixa probabilidade.....

a) O servidor estar escrevendo o IDNNN.DAT no momento em que o cliente está lendo o mesmo arquivo.

b) Manutenção do disco....o cara estar fazendo a manutencao do disco do servidor (apagando o lixo, diretórios anteriores) e clientes estao acessando bixo... (ainda não sei como evitar isso). ...talvez como o cara está no servidor, ele pode desligar o server enquanto faz manutencao OU....criar um arquivo BUSY.DAT no raiz....pra quando o cliente conectar ver que está ocupado e sair fora.... bom ainda vou pensar nessa parte....

Não sei se essa portuguesada toda vale a pena, mas é o que eu tenho de mais imediato no kengo. Não fui ver ainda nenhum estudo de caso pra ver uma abordagem mais elegante.... mas é aquela coisa....tudo por conta do automatismo....das aplicações....

E ae...alguem tem uma idéia mais simples.. ????
Como disse um banco de dados em rede resolveria o problema...mas como eu falei .... não existe essa possibilidade por uma série imensa de motivos.... e nem valeria a pena perder tempo com isso....dada a baixissima frequencia com que isso é feito.

Outra coisa seria a aplicacao servidora informar diretamente aos clientes que tem coisa nova no pedaço ....mas tem o problema dos clientes não estarem conectados na hora... por isso desisti de saida do processo....

Ideias ????

Vlw.

em cima da solução usando ftp, em vez da WS central criar arquivos *.DAT com a descrição dos arquivos, utilize pastas ou subdiretórios com nomenclatura indicando a versão e/ou data da atualização... daí resolve o problema de conflito do cliente ler e a central escrever no mesmo arquivo.

Quando a central vai criar uma nova atualização, ela cria um subdiretório no ftp como por exemplo 2007_09_17_08_00 (atualização das 8:00 de 17/9/2007). Dentro desse diretório, ela cria um arquivo LOCK só como flag, coloca os arquivos de update e apaga o LOCK "liberando" a atualização. Caso as atualizações sejam diferentes para cada cliente, pode ser criado um subdiretório tipo Cliente01 e dentro desse subdiretório, colocar os subdiretórios das versões de update.

A lista de arquivos para update é simplesmente a listagem de todos os arquivos no subdiretório da versão de atualização utilizada.

O cliente, quando "resolve" fazer update, conecta-se ao ftp e pega a lista de subdiretórios, verifica a mais recente que não contenha o arquivo LOCK e pega todos os arquivos pra fazer a atualização necessária. Caso a versão que o cliente possui esteja muito defasada (quando o cliente percebe que existem várias versões mais novas que a dele, pode-se fazer a atualização um por um ou, se for possível, já atualizar pra mais recente duma vez. Obviamente o cliente deve armazenar a versão que ele tem instalado em algum lugar...

Essa estrutura de controle de versão dos updates por subdiretórios tem a vantagem de manter um "histórico" de updates, além de quase eliminar problema de concorrência de cliente com a central e também permitir que clientes com diferentes versões possam se atualizar sem problemas.

Outra solução semelhante é chutar o ftp e criar um servidor de arquivos central com um diretório compartilhado com esses subdiretórios... os clientes mapeariam ou acessariam esses arquivos por rede, podendo nesse caso, até usar o comando copy do shell do windows... o que seria mais fácil que o comando ShellExecute ->cmd ->copy? Todo mundo sabe usar copy...

Pra ser mais fácil que isso, só usando algum componente pronto pra delphi que controle update, ou, se conhecer, usar um servidor CVS e um cliente cvs de linha de comando com as configurações apropriadas pra sobrescrever sempre... mas se já tem um servidor ftp rodando, melhor usar ele, pelo menos fica 1/2 byte mais difícil do que o copy direto pra algum curioso ficar fuçando no servidor de update.

Se quiser facilitar a manutenção mais ainda, cada cliente pode criar um arquivo no raiz do ftp de atualização contendo a última versão que ele "pegou", atualizando sempre esse arquivo em cada update. Isso permite que uma rotina verifique todas as versões dos clientes e também possa apagar os updates que já não estão mais sendo utilizados... e dá pra fazer um "relatório" dos clientes... os clientes também podem colocar mais informações nesses arquivos de informação de update, como por exemplo, falhas ocorridas, número de acessos, etc.. daí dá pra criar uma rotina que varre esses arquivos e mostre o que tá acontecendo com cada cliente, sem sequer acessar o cliente.

PS. A solução por servidor de arquivo facilita o cliente pois pode-se usar linguagem shellscript pra fazer o copy, chutando o delphi pro lugar dele. Mas servidor de arquivos, CVS e FTP implica no cliente conhecer o endereço do servidor... a descrição do problema tava o inverso

Eh...uma das coisas que podem ser feitas tambem ehehehehe
Mas eu já guardei essa solução na manga meu filho ehehehehe
obrigado..pela nova visão do problema....
mas eu quero sim deixar o FTP Server bem longe das mãos malignas
de usuários curiosos....realmente eheheheheehe

Gostei do bagulho do cliente criar um tag de atualização.
Assim o cara fica sabendo realmente se o buc* entrou lá.

Todos os IP's sao fixos...podes crer ....eh uma doideira...fiquei com os
dedos coçando pra fazer essa parada que tu falou ae ....
mas ...preciso terminar o básico antes....

Mas tá lindo, obrigado... ces precisam ver o que é um servidor rodando 80 conexoes de Audio sobre IP ....no gás.... dá gosto de ver....
Quando visitarem recife um dia e forem numa estação de metro e ouvir uma musiquinha.... vao lembrar do paraiba eheheheheeheh

Rio de Janeiro e Belo Horizonte que me aguarde...tamo chegando com força máxima.... é nóis na fita mano !!!!!

Jean, Em que pé esta o seu invento?

A respeito do servidor ftp, vc pode colocar o servidor ftp numa porta alta da maquina, assim vc esconde o ftp dos curiosos.

De toda forma acho que seria interessante voce usar o Lazarus para fazer um servidor de rede. O Lazarus é gratuito, tem componentes bacanas para vc usar.

me procura no MSN caso precise de ajuda com o Lazarus.