Provide advanced socket API support so that applications such as "ping", "traceroute", and other such applications can be developed with the Java 2 Standard Edition without restoring to platform specific native code.

At this time there are currently no standard APIs for developing portable
advanced socket applications.

Specific requirements that will be examined are :-

- Support for ICMP, ICMPv6, IGMP, IGMPv6 socket types.

- Advanced Sockets API for IPv6 (RFC 2292).

- An API for some common uses like Ping & Traceroute as a convenience.
Posted Date : 2006-08-18 12:37:12.0

N/A

A note to developers on the JDC :-

4093850 "ICMP protocol support a.k.a. PING applets" was a long
standing RFE seeking ICMP/raw sockets support. It attracted approximately
250 votes on the JDC. It became clear from the feedback to the RFE
that there were broadly two requirements :-

- Advanced & Raw Socket support - needed by those developing network
tools (such as ping & traceroute), and networking daemons (such as
in.ndpd).

- "ping" support where an application needs to determine if a 
host is reachable or not. 

Accordingly we have split 4093850 into 2 RFEs :-

4727550 is tracking the requirement for complete raw socket support
4639861 is tracking the requirement to test reachability of a host.

4093850 was closed as a duplicate of 4639861 and hence the JDC votes
& customer records were automatically transfered to 4639861.

  xxxxx@xxxxx   2002-08-08
Posted Date : 2006-08-23 02:30:10.0

I created a thread about this RFE in SDN forum:
    http://forum.java.sun.com/thread.jspa?threadID=762371
Hope it will get us some feedback soon.
Posted Date : 2006-08-23 02:30:10.0

In about one month (from 2006-08-23 to 2006-09-20), we don't see enough input in the SDN forum thread for this RFE. Seems there's no enough interest for it. Please add your comments/requests there, we'll keep monitoring the thread.

Will consider this RFE if we gather enough demands.
Posted Date : 2006-09-20 10:07:59.0

I think that is very important to Java to support ICMP,
there are alot of applications that need this feature.

Please consider a complete RAW socket support for tiger.

To enable this long time awaited feature without
compromising the Java security, we should define a specific
permission that is disabled by default (even when ran in a
"trusted application" context, aka as a standard extension
or as a certified JNLP application ), that only a person
having complete control on the VM could enable the
permission (by changing the VM default permission). Doing so
will not break the Java security model in any way.

This permission will restrict the access to the C feature
setsockopt with SOCK_RAW or SOCK_PACKET (if the later is
available on the OS) in the method setOption (cf.
http://java.sun.com/j2se/1.4.2/docs/guide/net/socketOpt.html ).

Please do realy consider this RFE, as this is something very
important we need to build advanced network tool in 100%
Java and we can no more wait for the release as there is no
alternative solution by now to do this :(

I need that for my games

100% support this one. We need this to create 
prototype network protocol or routing algorythm...

Phone cellular are based on Java...Including JavaRawSocket class in every mobile devices I think that will be a new start of point for a future Java developer, first that .NET will go on over Java... I think Java developer must understand the important of such class ....

hone cellular are based on Java...Including JavaRawSocket class in 
every mobile devices I think that will be a new start of point for a future
 Java developer, first that .NET will go on over Java... I think Java
 developer must understand the important of such class ....

If you feel that you are breaching some security lines, then atleast offer this feature as an add-on/optional package. Without this access, java programs have to depend on some other native programs/languages. Think of java as a language, you will understand the importance of this feature to java developers

I need my application to monitor remote-deployed java clients.

This is the one feature missing to allow Java developers to write very sophisticated network apps (firewalls, for example) without the help of 3rd party C libraries.  I am surprised that a feature with so much community support still isn

wierd, my message got cut off. well, to summarize the rest of the message, if the problem is manpower, then add it as a JCP and I (as well as many others) will sign up to help get the implementation right.

As a remark, Loria has already implemented a patch that enable RAW_SOCKET in the J2SE see http://w6.loria.fr/software/JDKv6/download/libnet6.tgz as part of their IPv6 effort.

Obviously, I am affraid the code is no more matching with the J2SE1.5. But it shows that RAW Socket is not that complex to implement !

As noted in my previous comment, this will not introduce any security issue as to use the RAW socket option you will have to get an extra permission that will not be enabled by default (in application, applet  and JWS policies). Hence you need to have the appropriate rights to access the policy file, plus you will have to get the appropriate rights on the system to use the RAW socket feature. As a consequence, this will be very secure and will not introduce any breach in the Java security model.

So please realy consider that for mustang !!!

Support for raw sockets would be great. My project JGroups (http://www.jgroups.org) sends UDP datagrams. If a datagram is larger than the MTU (e.g. 1500b on ethernet), it will get fragmented by the IP layer. JGroups does retransmission of dropped messages at the UDP datagram level (for IP multicasting), so if 1 datagram is broken into 20 IP packets by the IP layer, then *one* dropped IP packet leads to retransmission of 20 IP packets !
If I had access to IP packets, I could do retransmission at the IP level (for UDP datagrams and IP multicast datagrams), which would be much more efficient.

bela-jg: the solution to your problem is actually very simple. break the datagram packets into more manageable pieces in your code.  When I wrote an implementation for Tree Reliable Multicast, we never had to resubmit more than 1 packet, even if they were out of order.

I am getting ready to test it out, but this seems to be a fairly simple and straightforward solution... Apache v2 licensed.

http://www.savarese.org/software/rocksaw.html

I need it to design specific network projects.

This ISN'T a security issue!!!, if you want to limit a running environment, run it with Security Manager. Otherwise restrictions must be made at OS-level, but dropping a feature that is possible using native code must not be done.

As of two months ago - I had to implement a network sniffer for a demonstration of IPv6.  I used JpcapDumper (Java) and libpcap (native) on Linux and winpcap (native) on Windows.  Worked well - but bug in native code did not recognize IPv6 packets - so I corrected in Java code (the callback gives us the entire stream as a byte array).  Worked great - and highlights the point - I want to write code in Java that can filter / manipulate the entire ethernet byte stream (this could be used to classify and mark packets for QOS purposes) - written once.  Unfortunately, without a Raw Socket API - this is not possible :(

Another project required creating and sending UDP datagrams with a specific type in the ethernet header - a C programmer got the gig :(

What gives?  Please figure out the problems.

Dear all,

The fact such a key feature is still "In progress" for years is bringing IMHO value to the ones that are pushing that Java Se RI (aka JDK) should be opensourced ASAP in other to allow contributors to participate to the code enhancement.

The JDK project has to eveolve in the same kind of management and opening that the Glassfish ( Java EE 5 RI) has done ! This has proven to be a sucessfull story among Sun and the community.

Anybody from Sun reading this line, please consider this is very important for the future of Java SE !

Rgs,
JB

I support this enchancement

Regarding the attempt to get feedback:

I don't think a single post to the SDN forums is a good way of gathering feedback.  I don't know about everyone else but I only visit those forums as a last resort and only if I'm looking for a solution to some problem.  You would have a lot more visibility if you solicited feedback via a blog posting and asked theServerSide/JavaLobby and a few of those sites to post an article as well.

I'm working on a custom network protocol using UDP sockets.  Having access to the packet header would really help.  For example, my hashing implementation suffers because I have to obtain the source address from a String inside a SocketAddress object.  Because strings are immutable their contents must be copied into another array in order to perform the hash - this is a needless operation and almost doubles the time it takes to compute hash codes.

To all : as Java SE RI is now GPLed, anybody with strong raw socket skills willing to be the first one to push a patch on his blog ? ;-)

This would help to show RI managers that this can be done in a safe way (requiring extra permission for instance that is not granted by default).

These are things we can see as java is being opensource

Whoever is holding this up should do a google search and see how many people are looking for this and have created workarounds.  At the very least, ICMP should be supported without Admin privileges being required.  I can't believe this wasn't implemented.  It's so fundamental

ICMP is the basis of any network monitoring tool. It's a huge lack not to have it in Java.

One start idea could be to have:

- A new RawSocket class extending from DatagramSocket where you can send & reveive packets applying some filter on a given and get 

Example of such raw socket on Java
http://www.savarese.org/software/rocksaw/

- Another class RawSocketManager could be defined to create binding of underlying packet capturing facility thru an SPI. For instance, binding can be provided for libpcap and winpcap when required when receiving more raw packets.

Accessing directly a RawSocket for receiving and sending will mean accessing only at IP level and depending on System specific capabilities.

Accessing to RawSocketManager would mean, having advantages of underlying implementation (access to link layer for instance).

All this will enable IP, Etherne Java libraries to be build so that application can then have more convenient view of the raw transmissions.

Raw socket is a MUST do for lots of advanced networkings that owuld benetif to both enterprise and research worlds. 

Our ability to write network management software in Java is frustrated by Java's lack of support for ICMP. What can we do to encourage you to add ICMP support?

Very important feature! Doing Runtime.exec("ping") creates too much overhead and too many problems

I have to say that I am severely disappointed that after 7 years, the most requested RFE is still getting a "11-Closed, Will Not Fix".  That is the kind of thing that makes me want to drop Sun's implementation which I have been a very strong advocate of since v1.02.

I need a code catch output of traceroute. Calling Runtime.exec("traceroute") seems not to be a viable solution.  Any help from java community?