Olá a todos,
Bom pessoal. Eu estou querendo um exemplo de código se alguém tiver que efetue o upload de um arquivo ou ao menos me aponte uma direção do que devo procurar. Valeu e até.Usando que protocolo?
Se for FTP:
http://www.faqs.org/rfcs/rfc959.html
Se for TFTP:
http://www.faqs.org/rfcs/rfc1350.html
Se for HTTP:
http://www.faqs.org/rfcs/rfc1867.html
Se for torrent:
http://wiki.theory.org/BitTorrentSpecification
Então colega,
Seguinte. Não é nenhum desses. Eu quero realmente implementar um aplicativo usando a linguagem Java que permita eu fazer o upload de um arquivo. 8) :shock: :DVocê sabe o que é um protocolo?
Para que duas máquinas se comuniquem e troquem um arquivo, elas precisam saber como conversar. O protocolo estabelece as regras dessa conversa. Nos documentos que te passei, tem todas as regras de vários protocolos comuns de internet. Basta fazer um programa java que implemente essas regras.
[quote=ViniGodoy]Você sabe o que é um protocolo?
Para que duas máquinas se comuniquem e troquem um arquivo, elas precisam saber como conversar. O protocolo estabelece as regras dessa conversa. Nos documentos que te passei, tem todas as regras de vários protocolos comuns de internet. Basta fazer um programa java que implemente essas regras.[/quote]
Vejamos. É um conjunto de regras padronizadas que permite a interação entre objetos distintos. Seria isso? Tá colega. Eu sei isso. Na verdade eu já fiz aplicativos que permitem trocas de mensagens. Se você fosse citar protocolos seria mais interessante que tivesse me citado o TCP ou UDP que é algo muito mais prático do que jogar RFCs. Eu estou querendo um código que faça essa troca como um algoritmo que eu tenho que funciona com o mesmo princípio de um chat faz só que ao invez de trocar caracteres quero quer envie arquivos. É simples.
É impressão minha, ou você adotou um tom hostil? Antes de sair se ofendendo, ou achando que te chamei de burro, lembre-se que:
a) Eu não te conheço. Não faço a menor idéia do seu estudo ou conhecimento prévio;
b) Você até então não falou que aplicação está desenvolvendo, ou deu qualquer detalhe a respeito de que tipo de comunicação você queria fazer. “Um arquivo” pode ser algo pequeno como um texto, ou gigante como um DVD, pode ou não ter reinício, pode ou não exigir confiabilidade;
c) Você mesmo pediu que alguém “pelo menos te apontasse uma direção”.
Ainda assim, te passei as RFCs dos principais protocolos de comunicação de arquivos via internet. Se quiser implementar um servidor de qualquer um deles, ali está todo material. Eu mesmo já implementei um servidor FTP, TFTP e DHCP, só usando as RFCs.
Finalmente, se eu citasse o TCP ou UDP, não estaria citando nada que te ajudasse. Primeiro, porque todos os protocolos acima rodam sobre TCP ou UDP, são protocolos de camada 7. O TCP e o UDP são protocolos da camada de transporte (4), eles só servem para permitir que máquinas distantes conversem, mas não especificam como. Esses protocolos estão encapsulados na classe socket, e você jamais os manipularia diretamente. A troca de arquivos é feita por um protocolo sobre eles, um protocolo de aplicação, como os que citei acima. Portanto, de nada adiantaria eu ficar discorrendo aqui sobre protocolos de camadas tão baixas.
Se você quer simplesmente um software que faça a troca de arquivos, escolha o protocolo que quer comunicar e comece a procurar material DEPOIS disso. Ou, pelo menos, cite as características que você quer para essa troca.
- O cliente poderá se comunicar com mais de um transmissor ao mesmo tempo?
- O cliente poderá reiniciar a transferência de onde parou, caso a aplicação caia?
- O protocolo deve fornecer arquivos para várias máquinas numa rede simultanea?
- É uma troca simples, tudo ou nada?
- É para rede local ou internet?
Dependendo da resposta, você escolhe o protocolo e aí sim, procura por códigos que o implementem.
Só impressão mesmo. Só te dei uma dica que quando alguém tiver problemas com essa parte de aplicativos usando rede é mais interessante você indicar o uso de protocolos TCP ou UDP do que empurrar RFCs para alguém. Achar que alguém mesmo iniciante irá ler esse material todo para fazer um aplicativo realmente é um equívoco na minha opinião. Depois, acho que talvez só o DHCP deve usar o UDP, já que os outros exigem confiabilidade. Depois, dizer que esses protocolos são da camada 7 é questionável já que o modelo TCP/IP em sua camada 5 engloba as duas primeiras camadas do modelo OSI. Como é que é? O TCP e UDP são da camada 3? Em que planeta você está? Volta pra Terra. Mas nem no OSI e nem no TCP/IP o TCP ou o UDP se encontram em camada 3. Olha com todo o respeito, mas te recomendo ler esses RFCs que me indicou, pois está precisando. Também pode aproveitar o livro do Tanembau. Ótimo sobre redes.
- O cliente poderá se comunicar com mais de um transmissor ao mesmo tempo?
Resposta: Não.
- O cliente poderá reiniciar a transferência de onde parou, caso a aplicação caia?
Resposta: Não.
- O protocolo deve fornecer arquivos para várias máquinas numa rede simultanea?
Resposta: Não.
- É uma troca simples, tudo ou nada?
Resposta: Sim.
- É para rede local ou internet?
Resposta: Local.
Cara, ainda não entendi pq vc está com esse tom agressivo.
Realmente, eu confundi, o TCP é um protocolo de camada 4, transmissão. Não confunda, estou falando do protocolo TCP, não da pilha TCP/IP. A pilha TCP/IP usa outros protocolos, como o IP. Não cabe aqui comparar os modelos OSI (que é usado apenas para referência) com o modelo de facto TCP/IP.
Quando escrevi o número, pensei no IP, esse sim, de camada 3.
Dos protocolos que citei, o TFTP usa UDP, e implementa um protocolo de verificação rudimentar, mas bastante adequado para redes locais. Provavelmente é o protocolo que você vai usar. Outra opção, que é adequada em internet, é o FTP. Como ele roda sobre TCP, tende a ser mais eficiente, mas um pouco mais complexo de implementar. O protocolo do torrent também usa UDP, para permitir a conexão entre os peers.
Você pode procurar classes para o cliente FTP no projeto jakarta. Elas estão prontas, entretanto, não existem lá as classes dos servidores. Há alguns servidores open source na internet, mas a maioria vem com interface gráfica, e não só a API.
O autor do livro de redes chama-se Tanembaum, e não Tanembau. Para sua informação, eu não só tenho graduação com ênfase em redes, como trabalho com protocolos de comunicação há mais de 10 anos, em empresas como a VISA e a Siemens. Conheço a fundo todos os protocolos de rede que comentamos, além de protocolos para voz sobre IP e outros tipos de aplicação. Já perdi as contas de quantas aplicações em rede implementei, inclusive alguns sistemas distribuídos.
Se vc manja tanto de protocolos e rede como diz manjar, não entendi, porque veio pedir ajuda no fórum?
Eu não estou com tom agressivo. É que você colocou informações aqui incorretas. Eu não confundi você sim. E onde eu disse que TCP é da camada 5 cara. Para de viajar ok. Poste aqui onde eu fiz tal afirmação. O FTP roda sobre IP e por isso é mais eficiente? O que quer dizer com roda sobre IP?
Desculpe, mas não costumo a interpretar frases como:
Como tom amistoso.
Então, logo depois que postei eu corrigi ali, enquanto relia a mensagem. Também corrigi a afirmação onde dizia que você falou que o TCP era de camada 5. Sua frase ficou estranha, pq vc subitamente mudou o modelo de referência (que era o OSI até então) para falar do número da camada no modelo TCP/IP.
O protocolo FTP roda sobre TCP, por isso é um pouco mais eficiente. Embora o TCP tenha um pouco mais de overhead, isso é compensado com diversos algorítmos eficientes, como pigbacking de pacotes de confirmação, coisa que será muito difícil implementar em UDP, e coisa que o TFTP faz de maneira bem rudimentar. Se você pensa em migrar seu aplicativo para internet um dia, parte direto para o FTP.
Se você não pensa, e tem certeza que a rede será sempre a local, confiável, aí você pode fazer em TFTP mesmo, por ser mais fácil.
Como falei, pega lá as classes do jakarta, procura um server que já implementa open source e copia as classes de lá.
Novamente, falar no início de UDP ou TCP não adiantaria nada. Esses dois protocolos já são implementados nas classes Socket e DatagramSocket (ou SocketChannel e DatagramChannel), serão implicitamente usados de um jeito ou de outro. Simplesmente procure pelo protocolo de transmissão de aplicação que você quer, e lá haverá instruções sobre qual desses dois usar.
Não tomando as dores de ninguem mais ele precisa de algo pronto e mastigado no estilo Delphi da vida (pegue pronto e modifique) funcionou blz não funcionou baixo outro.
package br.com.java;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.net.SocketException;
import org.apache.commons.net.ftp.FTPClient;
public class FTPConnect {
public static void main (String[] args) throws SocketException,
IOException {
FTPClient ftp = new FTPClient();
ftp.connect( "ftp.seudominio.com.br" );
ftp.login( "usuario", "senha" );
FileInputStream arqEnviar =
new FileInputStream("/Documents/artigoFTP.doc");
if (ftp.storeFile ("meuarquivo.doc", arqEnviar))
System.out.println("Arquivo armazenado com sucesso!");
else
System.out.println ("Erro ao armazenar o arquivo.");
}
}
Funciona que e uma blz
Exatamente. Mas o problema é que as classes do Jakarta só tem o Client, não o server.
Como ele não especificou se ele vai ou não implementar o servidor, é difícil indicar qualquer coisa.
De qualquer forma, já havia falado para ele baixar essas classes: http://commons.apache.org/net/
Colega. Eu coloquei isso de “que planeta”, só que de forma humorística. Só isso. Eu citei o TCP/IP porque no fundo este é o usado na prática como modelo de referência. O OSI é só mais uma coisa didática, porém pouquíssimo prático. Só coloquei o TCP/IP para mostrar que foi um erro mesmo e não que você tinha se confundido como os modelos de referência. A tá aí sim. Porque quando você colocou que rodava sobre IP eu já estranhei, pois não tinha sentido tal afirmação.
Agora vou checar esses que você citou de Classes em Java. Qualquer coisa eu retorno.
Enfim, você precisa implementar os dois lados da comunicação, ou só o cliente?
Se você precisar implementar os dois lados, não tem muito como fugir de fazer no braço seu servidor. Um servidor FTP sem autenticação é bastante simples de ser implementado.
Já postei aqui no GUJ algumas classes para lidar com detalhes irritantes do Java, como o fato dele não tem tipos unsigned:
Não entendi a sua perunta. Sua pergunta foi “você precisa implementar os dois lados da comunicação, ou só o cliente?”. Olha. Até onde eu sei, se eu for implementar um lado obrigatoriamente tenho que implementar o outro. Mas a questão é que quero implementar um client/Server.
Não necessariamente. Como o FTP é um protocolo padrão, vc poderia estar comunicando com outra aplicação, que já tivesse isso implementado.
Se a troca de arquivos for muito simples (um arquivos só, estilo messenger, sem listagem de diretórios nem nada disso), você poderia criar um protocolozinho básico, na sua aplicação mesmo.
Algo como:
a) Enviar um int dizendo o tamanho do arquivo;
b) Enviar o arquivo byte-a-byte.
Esse sim, é bem fácil de fazer. Para obter o tamanho do arquivo, use a classe RandomAccessFile.
Tá. Tudo bem. Tendo isso implementado do outro lado realmente. Mas como eu disse não é o meu caso. Esse byte a byte acho que já me serve. Como posso fazer isso? Vou checar essa classe citada por você.
Vou ver se escrevo um exemplinho pra vc e te mando.
Seria de grande ajuda. É que no meu caso tem que ser algo genérico. Ou seja, qualquer arquivo. Enquanto isso vou continuar pesquisando com base nas suas dicas.