Enviar varios tipos de objeto no socket

olá,

estou com uma duvida em qual seria o melhor jeito de criar uma comunicação entre sockets que permita receber varios tipos de objetos diferentes…

atualmente minha classe está ± assim (deletei a parte inutel):

Listener:

BufferedReader msgFromClient = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); while(true){ if((msg = msgFromClient.readLine())!=null){ // faz o tratamento } }

metodos do Sender (vem do Flex):

[code]public function sendImageByteArray(ba:ByteArray):void{
writeBytes(ba);
flush();
}

	public function send(o:String):void{
		writeUTF(o);
		flush();
	}[/code]

até ai tudo bem, tudo oq eu mando de um lado (do Flex), chega no Java…

acontece que… eu preciso enviar tanto mensagens em texto, quanto imagens, e outros arquivos.
como seria o melhor jeito de fazer o Java entender quando está vindo um arquivo ou apenas texto?

pois se eu envio uma string do Flex (pelo padrão UTF)
a palavra “batata”
chega como 6 B A T A T A 0
jah q 6 eh o tamanho da String enviada e 0 o terminador…

entao se eu envio um array de bytes…
ele vai direto os \u0000 ~ \uFFFF

não achei um modelo de como identificar tudo que está vindo de forma mais simplificada…
tinha feito algo mais gambiarrento enviando uma UTF antes de enviar um bytearray para o Java identificar q eh uma imagem q esta vindo, mas não sei se é o mais ‘correto’…

pensei em tambem usar a classe DataInputStream (atualmente esta com a BufferedReader) que contem metodos para ler byte[], UTF, entre outros tipos…
BufferedReader.readLine() é indicado para esse caso?

obrigado =]

ja que ninguém respondeu… eu faria mais ou menos como você disse, teria um bufferedInputStream, receberia os dados por ele, no começo você ter essa “gambiarra” de dizer la qual o tipo do dado, dependendo do tipo do dado você converte isso para string, ( se for o caso no próprio construtor de string passando o array de bytes com os bytes da string…), de qualquer forma isso ficaria mais para processar esses bytes ver o tipo do dado, por que para receber você receberia como bytes de qualquer forma…

disse ja que ninguém responde por que também não sou nenhum especialista especificamente nisso…

pois é tive que resolver assim mesmo, funcionou perfeitamente,
porem fico limitado a ‘single-thread’…
logo, tenho que esperar o arquivo terminar de ser enviado, para voltar a enviar comandos por UTF…

//variaveis
byte[] buffer = new byte[1024];
int size;
String msg;
IncomingType incomingType; //ENUM

//THREAD
while(true){
if(incomingType == IncomingType.UTF){
	if(((msg = msgFromClient.readUTF())!=null)){
		//se receber UTF iniciando por "IMG", muda o incomingType para IMAGE
	}
}else if(incomingType == IncomingType.IMAGE){
	if(((size = msgFromClient.read(buffer))!=-1)){
		//recebe recebe recebe e qdo terminar volta pra incomingType.UTF
        }
}else if(incomingType == IncomingType.FILE){
					
} // e entao vc adiciona quais tipos vc kizer...
}

bom… quanto a ter multiplas threads, eu pensei num caso aqui…

e se você tivesse um VO por exemplo, vamos usar o exemplo da imagem:

você teria nesse seu VO um identificador unico para a imagem especifica (te permitindo enviar/receber mais de uma imagem de uma vez) e uma lista de bytes.

você precisaria de um mapa para estas imagens recebidas, usando o identificador unico como chave deste mapa, e o seu VO como valor. Você vai precisar também de uma queue que vou falar daqui a pouco.

cada vez que você recebe mais um objeto com o mesmo id (chamamos assim o identificador unico), você adiciona os bytes deste no final do objeto com mesmo id que tem no mapa de imagens (se não existir no mapa um objeto com a chave = esse id você o insere).

quando for para terminar o arquivo você manda o seu vo com a lista de bytes nula, assim ao receber você verificando se a lista está nula, caso não você “concatena” esses bytes no vo do mapa, caso esteja nula você pega esse VO do mapa, remove-o do mapa e o insere na queue.

Esse mapa tem que ser o mesmo para multiplas threads receberem bytes de multiplas imagens e popularem-no (acredito que você tenha que deixa-lo estatico na classe).

Assim acredito que você possa ter multiplas threads enviando/recebendo dados de multiplas imagens, a unica restrição mesmo que vejo para isso seria você ter uma unica thread enviando/recebendo dados de uma mesma imagem.

Você poderia ter também multiplas threads consumindo essa queue, pegando os VOs e gravando a imagem onde tiverem que gravar…

você poderia replicar isso também para arquivos, mas não vejo necessidade de ter isso para receber strings (mesmo para imagens ou outros tipos de arquivos, só vejo necessidade disso em casos onde seja mesmo necesária a performance).

Eu nunca fiz algo assim, não sei o ganho que isso traria (ou se eu to viajando mesmo) mas acredito que funcione, eu estou falando alguma bestera?

pois é,
tinha pensado que teria de ser assim mesmo…

porem se for aplicar esse metodo acho que vou aumentar o tamanho de buffer…
jah q a cada buf, eu teria q mandar informações adicionais sobre o ‘nome do arquivo’ de destino… oq consumiria mais banda…

vou começar a fazer uns testes de stress para ver se o sistema vai aguentar mtos usuarios enviando arquivos simultaneos…

assim que der certo posto o resultado
vlw ^^

posta sim… até agradeço por isso… costumo ser curioso quanto a testes desse tipo em algoritmos gerais, esse é um interessante…

você fez algum teste?

opa desculpa a demora hehe

sim, testei montando um servidor caseiro… e pedi pra outra pessoa ficar mandando arquivos separados por socket na minha conex…
funcionou muito bem, o unico limite eh claro, a minha Speedy haha…
a taxa de upload do cara nao passou de 30kb/s…
mas em rede interna funcionou bem e rapido que mal dava pra ver o arquivo sendo enviado…

eu comecei a montar um aplicativo tipo www.isketch.net/
para quem não conhece é um jogo de imagem-ação online,
só que de 2000 e pouco, ps: Shockwave player xD

entao estou sobrecarregando o servidor com varias salas e pessoas conectadas desenhando e enviando dados simultaneamente…
em rede local aqui na empresa esta funcionando muito bem…

em breve coloco um link aqui do meu servidor caseiro rodando o aplicativo, e vejo na net se a banda aguenta…

valeu ai por contar como que ficou