Sockets, RMI, etc...?

não consegue.
pura e simplesmente.
Em java não existe suporte a raw sockets.
Com TCP, voce consegue usar o stream e setar os bits de QoS, mas só. Não tenho certeza se java tem suporte a OOB data.

Com UDP, voce consegue mandar e receber datagramas, nada alem.

Ou voce escreve sua aplicação em 1 linguagem como C ou python que suportam raw devices ou então escreve uma classe com métodos nativos acessando 1 raw/netlink socket.
Talves, não tenho certeza, abrir o dispositivo de netlink via java.io funcione, mas não contaria com isso…

foi o q pensei mesmo, louds…

no caso de eu jah ter essas funcoes prontas em C++…

como eu faco p/ chamar essas funcoes via JAVA?? tem ideia??

falow

JNI é a solução mais simples.
da uma olhada em
swig.sourceforge.net

Ola, para que server JNI ??

Obrigado!

JNI é a api que voce usa para escrever rotinas em outras linguagens de tal forma que elas possam sem chamadas do java.

class A {
    public native int x();
}

‘int x()’ será implementada poruma função nativa que usara JNI para se comunicar com a JVM[/code]

Não se costuma dizer que “pode-se fazer qualquer aplicativo com Java”???

Porque esses recursos não são possíveis? :roll:

Pq essa é a parte que mais diverge entre SO’s e a que daria mais problemas por causa de permissões do SO.
Vejamos, windows 98 não tem suporte a raw sockets, no linux somente root pode criar 1.
A forma que o netlink socket funciona em linux e solaris é bem diferente…

É o tipo de coisa que daria trabalho demais pra tão pouco uso.
Ou seja, não existe a menor chance de voce escrever, agora ou em um futuro próximo, um programa de ping em java seu usar código nativo.

É +/- a mesma razão por que não temos acesso a STREAMS e unix-sockets…

valew pela ajuda, galera…

vou implementar o q o Java permite mesmo…
vou mandar pacotes via Socket e tb via DatagramSocket…

mas resta uma duvida…em ambos os casos, preciso ter tanto um cliente p/ mandar os pacotes qto um servidor na maquina destino p/ ficar “ouvindo” e receber os pacotes, certo??

valew

Somente para TCP, udp nao precisa…

eh q na API do DatagramSocket existe metodos send() e receive()…

por isso pensei q precisasse de algum programa p/ receber o pacote…

UDP é conectionless, ou seja, se não tiver alguem esperando o pacote do outro lado ele vai ser simplesmente descartado e 1 icmp pode ser gerado…

mas no caso, se eu quiser mostrar q chegou o pacote UDP mesmo…

entao preciso ter alguem recebendo os pacotes no destino, certo??

valew

Sim, precisaria de uma aplicaçao do outro lado escutando para saber se os pacotes conseguiram chegar, afinal UDP nao tem garantia de entrega.

Bom, com TCP também precisa ter alguém do outro lado escutando…

mas por que alguém ia precisar ou querer usar raw devices? Internamente, dependendo da escolha do usuário, vc escolhe um tipo de socket…

Vc tem um tipo de pacotes bem definido? Um pacote de TCP de uma aplicação telnet tem, tipicamente, um único caractere como dado. O resto é cabeçalho. Um vídeo numa aplicação streaming tipicamente tem pacotes UDP com um grande volume de dados, e muitas vezes o mesmo frame é enviado mais de uma vez.

Seja qual for o esquema que vc vai usar, se vc tem acesso à API java.nio, vc pode salvar-se um trabalhão utilizando Channels.

[]s!

Raw socket tem varias utilidades, como escrever programas que utilizam icmp e igmp. Ou ainda escrever programas que fazer probing e analise de redes.

Já com um netlink device você pode escrever qualquer tipo de software que envolva monitoramento, analise, filtragem ou manipulação de pacotes IP, nessa area voce tem softwares de IDS, firewall, tuneling, honeypots, etc.

Agora se java deveria ou não ter suporte para isso, são outros 500…

Para tunelling, acho eu que voce tode usar direto um dispositivo TUN/TAP do linux para isso…