From Michael.McMahon at Sun.COM Thu Nov 1 02:45:50 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 01 Nov 2007 09:45:50 +0000 Subject: UrlEncodedQueryString CCC request In-Reply-To: <4714B2B6.8010800@sun.com> References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com> <470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com> <470FF5DC.1030208@kennardconsulting.com> <4714B2B6.8010800@sun.com> Message-ID: <4729A04E.2000809@sun.com> Marc & Paul, I wonder if you have an opinion on the points/questions raised below? I'd like to get agreement on the general shape of the API before anyone goes off and reworks the existing proposal. Thanks Michael. Michael McMahon wrote: > I agree with most of the suggestions below. The main things > we want are: > > 1) alignment, ie. the JSR311 class extends the java.net class > although I would imagine that if JSR311 is finalised before jdk7 > then it will not initially extend it. So, it should at least be > aligned > sufficiently so that it could extend the java.net class in the future > > 2) then we combine the building capabilities of UriBuilder (probably > use that name also) > with the retrieval/query manipulation capabilities of > UrlEncodedQueryString. > I think the method names from UrlEncodedQueryString will have to > change though > eg addParameter() would need to be addQueryParameter() etc. > > Some questions. > > 1) I'm not familiar with the notion of "matrix" parameters. Google > seems to > only reveal one old w3c article about them. Are they more widely > used than this? > If the concept is more specific to JSR311, then I think I'd prefer > to leave them > out of the java.net. class > > 2) Initially I was sceptical about URI templates, and I do think that the > general class probably doesn't need any of the methods related to > reflection/annotation processing (of URI templates), but it does > look like a useful feature > and it's worth considering supporting the build() capability which > replaces > {} templates with specific instance values from the Map passed in. > The risk of course is that the specification for URI templates could > change > before it is standardised by the IETF. > > Thanks > Michael. > > Marc Hadley wrote: >> On Oct 12, 2007, at 6:31 PM, Richard Kennard wrote: >>> >>> > [UriBuilder has] 4 methods associated with accessing URI templates >>> of a class or method, but it is simple to generalize by removing >>> such methods >>> >>> This seems a good starting point. If I may propose a logical >>> progression: >>> >>> 1. We split JSR311's UriBuilder into a JSR311-specific version and a >>> generalized java.net version >>> >>> 2. We add further generalized methods into the java.net version to >>> cover the other URI segments (scheme, host, port, authority, user-info) >>> >> The JSR 311 UriBuilder has methods for scheme, host, port and >> userInfo. We did have authority too but removed it since its a >> composite of some of the others. >> >>> 3. We would now have a class that looks not unlike what I was >>> proposing last year. The java.net team's objection to this class >>> (which I agree is valid) was that some methods (queryParam, >>> matrixParam) are not strictly part of the RFC 2396 URI spec. So we >>> may split it again, into a 'strict URI' part and a >>> 'www-form-urlencoded query string' part (which I think is >>> essentially what queryParam and matrixParam are implying) >>> >>> 4. We agree that parsing and retrieving is also a useful feature and >>> include that (the class can still be called 'builder' - >>> StringBuilder has methods for retrieving, for example) >>> >>> I think how we do the split in 3) is the most important decision. >>> The java.net team and I tried two ways - a generalized superclass >>> and a specialized subclass, and a standalone class - and preferred >>> the latter, hence where we are with UrlEncodedQueryString today. >>> >>> What do you think? >>> >> I think it would make sense for the JSR 311 class to extend a >> generalized java.net class since we'd want to add support for URI >> templates. That support is pervasive so its not just a case of adding >> new methods, we'd want to override existing ones to allow URI >> templates to be used within their values. >> >> Regards, >> Marc. >> > From Marc.Hadley at Sun.COM Thu Nov 1 07:40:13 2007 From: Marc.Hadley at Sun.COM (Marc Hadley) Date: Thu, 01 Nov 2007 10:40:13 -0400 Subject: UrlEncodedQueryString CCC request In-Reply-To: <4729A04E.2000809@sun.com> References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com> <470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com> <470FF5DC.1030208@kennardconsulting.com> <4714B2B6.8010800@sun.com> <4729A04E.2000809@sun.com> Message-ID: <4DCBD0DE-8AC7-46BC-BE56-7B5D8A531B9B@Sun.COM> On Nov 1, 2007, at 5:45 AM, Michael McMahon wrote: > > I wonder if you have an opinion on the points/questions raised below? > I'd like to get agreement on the general shape of the API before > anyone goes off and reworks the existing proposal. > Some comments interspersed below. > > Michael McMahon wrote: >> I agree with most of the suggestions below. The main things >> we want are: >> >> 1) alignment, ie. the JSR311 class extends the java.net class >> although I would imagine that if JSR311 is finalised before jdk7 >> then it will not initially extend it. So, it should at least be >> aligned >> sufficiently so that it could extend the java.net class in the >> future >> I agree with the goal but we'd rather not be tied to jdk7. The current plan is to make the API available separately for jdk5 or later. Would we be able to bundle any jdk7 superclass to achieve that ? >> 2) then we combine the building capabilities of UriBuilder >> (probably use that name also) >> with the retrieval/query manipulation capabilities of >> UrlEncodedQueryString. >> I think the method names from UrlEncodedQueryString will have >> to change though >> eg addParameter() would need to be addQueryParameter() etc. >> The builder is strictly that, a builder, so I'm not sure if it makes sense to add read capabilities to it. Would it make sense to add the read capabilities of UrlEncodedQueryString directly to URI ? >> Some questions. >> >> 1) I'm not familiar with the notion of "matrix" parameters. >> Google seems to >> only reveal one old w3c article about them. Are they more >> widely used than this? >> If the concept is more specific to JSR311, then I think I'd >> prefer to leave them >> out of the java.net. class >> Matrix parameters aren't specific to JSR311, I believe that a number of Web APIs make use of them but I don't have an example at hand. >> 2) Initially I was sceptical about URI templates, and I do think >> that the >> general class probably doesn't need any of the methods related to >> reflection/annotation processing (of URI templates), but it does >> look like a useful feature >> and it's worth considering supporting the build() capability >> which replaces >> {} templates with specific instance values from the Map passed in. >> The risk of course is that the specification for URI templates >> could change >> before it is standardised by the IETF. >> That is a definite risk. Currently we are discussing more complex notations for representing things like default values, prefixes, suffixes etc. The simple {param_name} syntax is likely to survive though so its possible we could implement that initially and add full support in a subsequent release. Regards, Marc. >> >> Marc Hadley wrote: >>> On Oct 12, 2007, at 6:31 PM, Richard Kennard wrote: >>>> >>>> > [UriBuilder has] 4 methods associated with accessing URI >>>> templates of a class or method, but it is simple to generalize >>>> by removing such methods >>>> >>>> This seems a good starting point. If I may propose a logical >>>> progression: >>>> >>>> 1. We split JSR311's UriBuilder into a JSR311-specific version >>>> and a generalized java.net version >>>> >>>> 2. We add further generalized methods into the java.net version >>>> to cover the other URI segments (scheme, host, port, authority, >>>> user-info) >>>> >>> The JSR 311 UriBuilder has methods for scheme, host, port and >>> userInfo. We did have authority too but removed it since its a >>> composite of some of the others. >>> >>>> 3. We would now have a class that looks not unlike what I was >>>> proposing last year. The java.net team's objection to this class >>>> (which I agree is valid) was that some methods (queryParam, >>>> matrixParam) are not strictly part of the RFC 2396 URI spec. So >>>> we may split it again, into a 'strict URI' part and a 'www-form- >>>> urlencoded query string' part (which I think is essentially what >>>> queryParam and matrixParam are implying) >>>> >>>> 4. We agree that parsing and retrieving is also a useful feature >>>> and include that (the class can still be called 'builder' - >>>> StringBuilder has methods for retrieving, for example) >>>> >>>> I think how we do the split in 3) is the most important >>>> decision. The java.net team and I tried two ways - a generalized >>>> superclass and a specialized subclass, and a standalone class - >>>> and preferred the latter, hence where we are with >>>> UrlEncodedQueryString today. >>>> >>>> What do you think? >>>> >>> I think it would make sense for the JSR 311 class to extend a >>> generalized java.net class since we'd want to add support for URI >>> templates. That support is pervasive so its not just a case of >>> adding new methods, we'd want to override existing ones to allow >>> URI templates to be used within their values. >>> >>> Regards, >>> Marc. >>> >> > --- Marc Hadley CTO Office, Sun Microsystems. From richard at kennardconsulting.com Thu Nov 1 21:19:22 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Fri, 02 Nov 2007 15:19:22 +1100 Subject: UrlEncodedQueryString CCC request In-Reply-To: <4DCBD0DE-8AC7-46BC-BE56-7B5D8A531B9B@Sun.COM> References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com> <470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com> <470FF5DC.1030208@kennardconsulting.com> <4714B2B6.8010800@sun.com> <4729A04E.2000809@sun.com> <4DCBD0DE-8AC7-46BC-BE56-7B5D8A531B9B@Sun.COM> Message-ID: <472AA54A.7030304@kennardconsulting.com> Marc, > The builder is strictly that, a builder, so I'm not sure if it makes sense to add read capabilities to it Agreed. I actually don't think these two classes (UriBuilder and UrlEncodedQueryString) overlap much. How about I propose this as a direction: 1. JSR-311's UriBuilder plans to use UrlEncodedQueryString internally (not extending it) as an implementation detail. Pre-JDK7 implementations of JSR-311 ship with their own, internal implementation 2. The JSR-311 Expert Group advise the java.net OpenJDK team what features they would like to be able to use for the internal implementation Regards, Richard. From Michael.McMahon at Sun.COM Fri Nov 2 13:37:01 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 02 Nov 2007 20:37:01 +0000 Subject: UrlEncodedQueryString CCC request In-Reply-To: <472AA54A.7030304@kennardconsulting.com> References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com> <470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com> <470FF5DC.1030208@kennardconsulting.com> <4714B2B6.8010800@sun.com> <4729A04E.2000809@sun.com> <4DCBD0DE-8AC7-46BC-BE56-7B5D8A531B9B@Sun.COM> <472AA54A.7030304@kennardconsulting.com> Message-ID: <472B8A6D.6030708@sun.com> Here is my suggestion. It probably makes sense to keep two separate classes, even though UriBuilder can potentially be used to create any possible URI. I think it is still useful to be able to manipulate query parameters independent of the URI that they are to be applied to, and I think the ability to remove parameters and retrieve them individually makes sense for query params (though not so much for other URI fields). So, to that end, I propose: 1) We adopt UriBuilder with some methods removed (can be added back in sub-class defined in javax.ws.rs) but with a build() method added that takes a UrlEncodedQueryString 2) We remove the apply() methods from UrlEncodedQueryString because you build URIs now through UriBuilder. 3) Most methods in UrlEncodedQueryString need to be renamed. The word Parameter needs to be removed from all of them. So, appendParameter() becomes append(). I think appendParameters() should also be named append(). 4) The parse() and create() methods should have the same name, and possibly be aligned with the creation methods in UriBuilder 5) I'm having second thoughts about exposing the Map outside of the class. I'd like to look at the reason why we did this again. 6) I think the separator char should be specified at object creation time. I can't see any great benefit to it being specified at the time apply() was called (though I know there may be some cases we still need to support, where different separators are used in the same query string). Regards, Michael From rabelenda at gmail.com Sat Nov 3 14:38:01 2007 From: rabelenda at gmail.com (Roger Abelenda) Date: Sat, 3 Nov 2007 18:38:01 -0300 Subject: custom libraries Message-ID: <975ae7d10711031438v5589618dwb8e237fafa41f09a@mail.gmail.com> I made some libraries and i want opnejdk load them. I putted them in the lib/i386/client directory but it doesn't finds them. Where i may put the libraries? Do i need to make some changes? Thanks From Alan.Bateman at Sun.COM Mon Nov 5 01:28:11 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 05 Nov 2007 09:28:11 +0000 Subject: custom libraries In-Reply-To: <975ae7d10711031438v5589618dwb8e237fafa41f09a@mail.gmail.com> References: <975ae7d10711031438v5589618dwb8e237fafa41f09a@mail.gmail.com> Message-ID: <472EE22B.3090500@sun.com> Roger Abelenda wrote: > I made some libraries and i want opnejdk load them. I putted them in > the lib/i386/client directory but it doesn't finds them. Where i may > put the libraries? Do i need to make some changes? Thanks > If you are looking for help getting JNI code working then a useful place to search is the JNI forum [1]. There can be several reasons why your native methods cannot be found. Maybe you are missing the loadLibrary method to load your library, maybe the signature of the native method may not match its declaration, maybe you are missing an entry in a map file, .... In any case, you will likely need to provide more information if you want to get help on this issue. -Alan. [1] http://forum.java.sun.com/forum.jspa?forumID=52 From rabelenda at gmail.com Mon Nov 5 06:44:59 2007 From: rabelenda at gmail.com (Roger Abelenda) Date: Mon, 5 Nov 2007 12:44:59 -0200 Subject: custom libraries In-Reply-To: <472EE22B.3090500@sun.com> References: <975ae7d10711031438v5589618dwb8e237fafa41f09a@mail.gmail.com> <472EE22B.3090500@sun.com> Message-ID: <975ae7d10711050644s676d1328o510cc4a5808f33bc@mail.gmail.com> I solved my problem, it wasn't a matter of the openjdk, I was doing something wrong with the libraries. Anyway, the libraries can go in i386, client, etc, it wasn`t my problem. Thanks anyway. 2007/11/5, Alan Bateman : > Roger Abelenda wrote: > > I made some libraries and i want opnejdk load them. I putted them in > > the lib/i386/client directory but it doesn't finds them. Where i may > > put the libraries? Do i need to make some changes? Thanks > > > If you are looking for help getting JNI code working then a useful place > to search is the JNI forum [1]. There can be several reasons why your > native methods cannot be found. Maybe you are missing the loadLibrary > method to load your library, maybe the signature of the native method > may not match its declaration, maybe you are missing an entry in a map > file, .... In any case, you will likely need to provide more information > if you want to get help on this issue. > > -Alan. > > [1] http://forum.java.sun.com/forum.jspa?forumID=52 > From cormac.mullally at gmail.com Thu Nov 22 05:17:08 2007 From: cormac.mullally at gmail.com (cormac mullally) Date: Thu, 22 Nov 2007 13:17:08 +0000 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 Message-ID: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> Hello all, I'm working on a project at the moment that needs's access to the "type 0 routing header" in an IPv6 packet. RFC 2292 describes a nice API, which allows you access to the routing header, see http://tools.ietf.org/html/rfc2292#section-8.9 I see that JavaSE supports RFC 2553 Basic Socket Interface Extensions for IPv6, and from looking around it seems that Sun has no interest in implementing RFC 3542 or RFC 2292(RFC 3542 Obsoletes 2292). My first question is: Is there any one working on implementing RFC 3542 or RFC 2292 in the openJDK project? My second question: What are my options going forward? I am pretty new to working on such low level stuff so any advice on how I should proceed is welcome. I've done a bit of researching and here is a bit of a summary. I'm developing on windows XP, so its mostly around how I would provide this functionality on a windows enviornment, but in the end my application would have to work on other major platforms. Firstly as some of you may know "type 0 routing header" has caused a bit of controversy (see http://www.natisbad.org/ especially this presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf) and it seems that there is some security concerns. Does anyone have any comment on this? I see some people are not happy as applications have already been developed using this feature. Do you think "type 0 routing header" will be disabled by default in routers and hosts? Do you think a new method will be created to provide this routing functionality but more securly? So imagining that all is well with "type 0 routing header" and I will use it for my project, here are some of the solutions I have been looking at for implementing this on windows. 1. WinSock 2. Raw Socket on top Winsock 3. Winpcap 4.0 beta 3 supports IPv6 1. Winsock Winsock does not seem to support RFC 3542 or RFC 2292. As in there is no nice methods for adding routing headers as far as I can see. http://msdn2.microsoft.com/en-us/library/ms738649.aspx and http://msdn2.microsoft.com/en-us/library/ms738649.aspx 2. Raw Socket with Winsock Raw Socket as far as I can see gives you acess to the header and data parts of the packet. From my research this in theory seems to be possible with winsock see http://msdn2.microsoft.com/en-us/library/ms740506.aspx especially the IPV6_HDRINCL section. Windows XP SP2 seems to have limited the raw socket, see http://blogs.msdn.com/michael_howard/archive/2004/08/12/213611.aspx, but I think I should be sill OK as I'm working with UDP and I'm not trying to change the source address of anything. Does anyone have any advice on starting with raw socket programming? I have downloaded and am looking at Rock Saw at the moment(http://www.savarese.org/software/rocksaw/). Any other advice welcome. Does JavaSE or OpenJDK use raw sockets for its functionality, or does it do something else? I am going to start looking into this next. 3. Winpcap 4.0 beta 3 Haven't investigated much here. Does this run on top of winsock? Does anyone know can I send packets using winpcap? Network Packet generator (http://www.wikistc.org/wiki/Network_packet_generator) is built on winpcap, has anyone used this on windows? Thats my research for the moment. If you have any questions please get back to me. Thanks for reading, Cormac From cormac.mullally at gmail.com Thu Nov 22 05:37:00 2007 From: cormac.mullally at gmail.com (cormacmul) Date: Thu, 22 Nov 2007 05:37:00 -0800 (PST) Subject: Fwd: custom DatagramSocket and DatagramPacket In-Reply-To: <975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com> References: <975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com> <47277276.8020602@sun.com> <975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com> Message-ID: <13896659.post@talk.nabble.com> Hello Roger, I just submitted a mail there about RFC 3542 and RFC 2292 Advanced Sockets Application Program Interface (API) for IPv6. Do you implement anything to do with routing headers? I am working in academia as well and would be very insterested in talking about your solution. Are you visible in the subscribers list, maybe I could contact you by email? Thanks, Cormac Roger Abelenda wrote: > > I'm in an academic project implementing an ipv6 stack entirely with > java in the jvm, and make the jvm by default call my ipv6 stack. > Thanks for advice, i'll try. > > 2007/10/30, Alan Bateman : >> Roger Abelenda wrote: >> > Hi I'm implementing an DatagramSocket and a >> > datagramPacket and I want to subsitute the ones of the jvm with this >> > ones. If you know: where may I put my code and what shall I do to make >> > it compile when I compile the jvm?, and , what changes Ii need to do to >> > plug it into the original code to make the jvm call my classes when >> > somebody calls the original ones?. I thought to change the >> > classloader.c and the resolve.c. Any other options? thanks. >> > >> As DatagramSocket and DatagramPacket are created by public constructors >> then you'll need to replace the existing classes. As a first step, for >> testing purposes, it might be easier to prepend your classes to the boot >> class path rather than replacing the classes in the build. Another >> approach is to create a DatagramSocketImpl and use the >> setDatagramSocketImplFactory method to set a factory that instantiates >> your impl rather than the default. Can you provide a few more details on >> what you are trying to do? If you are trying to fix a bug or add a >> feature then maybe it would be easier to contribute changes to the >> existing code rather than replacing them. >> >> -Alan. >> > > -- View this message in context: http://www.nabble.com/Fwd%3A-custom-DatagramSocket-and-DatagramPacket-tf4718553.html#a13896659 Sent from the OpenJDK Networking Development mailing list archive at Nabble.com. From rabelenda at gmail.com Thu Nov 22 05:50:08 2007 From: rabelenda at gmail.com (Roger Abelenda) Date: Thu, 22 Nov 2007 11:50:08 -0200 Subject: Fwd: custom DatagramSocket and DatagramPacket In-Reply-To: <13896659.post@talk.nabble.com> References: <975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com> <47277276.8020602@sun.com> <975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com> <13896659.post@talk.nabble.com> Message-ID: <975ae7d10711220550j1b90cf4hd0a1b0a5fb441062@mail.gmail.com> Hello, I'm continuing a work that was started in 2006. We first improve the already implemented, and now we are gone to view the basics rfcs and implement the rest of the basic stack. I'll see tonight if i can, if we already have implemented thath rfc, but i don't think so. 2007/11/22, cormacmul : > > Hello Roger, > > I just submitted a mail there about RFC 3542 and RFC 2292 Advanced Sockets > Application Program Interface (API) for IPv6. Do you implement anything to > do with routing headers? > > I am working in academia as well and would be very insterested in talking > about your solution. Are you visible in the subscribers list, maybe I could > contact you by email? > > Thanks, > Cormac > > > Roger Abelenda wrote: > > > > I'm in an academic project implementing an ipv6 stack entirely with > > java in the jvm, and make the jvm by default call my ipv6 stack. > > Thanks for advice, i'll try. > > > > 2007/10/30, Alan Bateman : > >> Roger Abelenda wrote: > >> > Hi I'm implementing an DatagramSocket and a > >> > datagramPacket and I want to subsitute the ones of the jvm with this > >> > ones. If you know: where may I put my code and what shall I do to make > >> > it compile when I compile the jvm?, and , what changes Ii need to do to > >> > plug it into the original code to make the jvm call my classes when > >> > somebody calls the original ones?. I thought to change the > >> > classloader.c and the resolve.c. Any other options? thanks. > >> > > >> As DatagramSocket and DatagramPacket are created by public constructors > >> then you'll need to replace the existing classes. As a first step, for > >> testing purposes, it might be easier to prepend your classes to the boot > >> class path rather than replacing the classes in the build. Another > >> approach is to create a DatagramSocketImpl and use the > >> setDatagramSocketImplFactory method to set a factory that instantiates > >> your impl rather than the default. Can you provide a few more details on > >> what you are trying to do? If you are trying to fix a bug or add a > >> feature then maybe it would be easier to contribute changes to the > >> existing code rather than replacing them. > >> > >> -Alan. > >> > > > > > > -- > View this message in context: http://www.nabble.com/Fwd%3A-custom-DatagramSocket-and-DatagramPacket-tf4718553.html#a13896659 > Sent from the OpenJDK Networking Development mailing list archive at Nabble.com. > > From Michael.McMahon at Sun.COM Thu Nov 22 05:56:39 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 22 Nov 2007 13:56:39 +0000 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> Message-ID: <47458A97.8030201@sun.com> Hi Cormac, I don't think it's likely that Java SE will support RFC3542 in the near future. I can't say however, whether anybody is actually doing any work on trying to support it. It seems like a fairly specialised requirement, that the majority of IPv6 applications would not use. Have you looked at Linux or Solaris? I think these operating systems have good support for the advanced Ipv6 socket APIs. Hth, Michael. cormac mullally wrote: > Hello all, > > I'm working on a project at the moment that needs's access to the > "type 0 routing header" in an IPv6 packet. RFC 2292 describes a nice > API, which allows you access to the routing header, see > http://tools.ietf.org/html/rfc2292#section-8.9 > > I see that JavaSE supports RFC 2553 Basic Socket Interface Extensions > for IPv6, and from looking around it seems that Sun has no interest in > implementing RFC 3542 or RFC 2292(RFC 3542 Obsoletes 2292). > > My first question is: > Is there any one working on implementing RFC 3542 or RFC 2292 in the > openJDK project? > > My second question: > What are my options going forward? > > > I am pretty new to working on such low level stuff so any advice on > how I should proceed is welcome. > > I've done a bit of researching and here is a bit of a summary. I'm > developing on windows XP, so its mostly around how I would provide > this functionality on a windows enviornment, but in the end my > application would have to work on other major platforms. > > Firstly as some of you may know "type 0 routing header" has caused a > bit of controversy (see http://www.natisbad.org/ especially this > presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf) > and it seems that there is some security concerns. Does anyone have > any comment on this? I see some people are not happy as applications > have already been developed using this feature. Do you think "type 0 > routing header" will be disabled by default in routers and hosts? Do > you think a new method will be created to provide this routing > functionality but more securly? > > So imagining that all is well with "type 0 routing header" and I will > use it for my project, here are some of the solutions I have been > looking at for implementing this on windows. > 1. WinSock > 2. Raw Socket on top Winsock > 3. Winpcap 4.0 beta 3 supports IPv6 > > > 1. Winsock > Winsock does not seem to support RFC 3542 or RFC 2292. As in there is > no nice methods for adding routing headers as far as I can see. > http://msdn2.microsoft.com/en-us/library/ms738649.aspx and > http://msdn2.microsoft.com/en-us/library/ms738649.aspx > > 2. Raw Socket with Winsock > Raw Socket as far as I can see gives you acess to the header and data > parts of the packet. From my research this in theory seems to be > possible with winsock > see http://msdn2.microsoft.com/en-us/library/ms740506.aspx especially > the IPV6_HDRINCL section. > Windows XP SP2 seems to have limited the raw socket, see > http://blogs.msdn.com/michael_howard/archive/2004/08/12/213611.aspx, > but I think I should be sill OK as I'm working with UDP and I'm not > trying to change the source address of anything. > Does anyone have any advice on starting with raw socket programming? I > have downloaded and am looking at Rock Saw at the > moment(http://www.savarese.org/software/rocksaw/). Any other advice > welcome. > Does JavaSE or OpenJDK use raw sockets for its functionality, or does > it do something else? I am going to start looking into this next. > > 3. Winpcap 4.0 beta 3 > Haven't investigated much here. Does this run on top of winsock? Does > anyone know can I send packets using winpcap? Network Packet generator > (http://www.wikistc.org/wiki/Network_packet_generator) is built on > winpcap, has anyone used this on windows? > > Thats my research for the moment. If you have any questions please get > back to me. > > Thanks for reading, > Cormac > From cormac.mullally at gmail.com Thu Nov 22 06:42:34 2007 From: cormac.mullally at gmail.com (cormac mullally) Date: Thu, 22 Nov 2007 14:42:34 +0000 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <47458A97.8030201@sun.com> References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> <47458A97.8030201@sun.com> Message-ID: <30f52a160711220642j20e00749xe0ffd36448f8fad9@mail.gmail.com> Hi Michael, I aggree it is quite specialised, but I think it would be good for java to support this. Yes I would love to use Linux or Solaris but I have to support windows. I am going to look at the internals of the openJDK now and see how it works. Thanks for your help so far and I will let you know how I get on. Best Regards, Cormac On Nov 22, 2007 1:56 PM, Michael McMahon wrote: > Hi Cormac, > > I don't think it's likely that Java SE will support RFC3542 in the near > future. > I can't say however, whether anybody is actually doing any work on > trying to support it. > It seems like a fairly specialised requirement, that the majority of > IPv6 applications would > not use. > > Have you looked at Linux or Solaris? I think these operating systems > have good support > for the advanced Ipv6 socket APIs. > > Hth, > Michael. > > > cormac mullally wrote: > > Hello all, > > > > I'm working on a project at the moment that needs's access to the > > "type 0 routing header" in an IPv6 packet. RFC 2292 describes a nice > > API, which allows you access to the routing header, see > > http://tools.ietf.org/html/rfc2292#section-8.9 > > > > I see that JavaSE supports RFC 2553 Basic Socket Interface Extensions > > for IPv6, and from looking around it seems that Sun has no interest in > > implementing RFC 3542 or RFC 2292(RFC 3542 Obsoletes 2292). > > > > My first question is: > > Is there any one working on implementing RFC 3542 or RFC 2292 in the > > openJDK project? > > > > My second question: > > What are my options going forward? > > > > > > I am pretty new to working on such low level stuff so any advice on > > how I should proceed is welcome. > > > > I've done a bit of researching and here is a bit of a summary. I'm > > developing on windows XP, so its mostly around how I would provide > > this functionality on a windows enviornment, but in the end my > > application would have to work on other major platforms. > > > > Firstly as some of you may know "type 0 routing header" has caused a > > bit of controversy (see http://www.natisbad.org/ especially this > > presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf) > > and it seems that there is some security concerns. Does anyone have > > any comment on this? I see some people are not happy as applications > > have already been developed using this feature. Do you think "type 0 > > routing header" will be disabled by default in routers and hosts? Do > > you think a new method will be created to provide this routing > > functionality but more securly? > > > > So imagining that all is well with "type 0 routing header" and I will > > use it for my project, here are some of the solutions I have been > > looking at for implementing this on windows. > > 1. WinSock > > 2. Raw Socket on top Winsock > > 3. Winpcap 4.0 beta 3 supports IPv6 > > > > > > 1. Winsock > > Winsock does not seem to support RFC 3542 or RFC 2292. As in there is > > no nice methods for adding routing headers as far as I can see. > > http://msdn2.microsoft.com/en-us/library/ms738649.aspx and > > http://msdn2.microsoft.com/en-us/library/ms738649.aspx > > > > 2. Raw Socket with Winsock > > Raw Socket as far as I can see gives you acess to the header and data > > parts of the packet. From my research this in theory seems to be > > possible with winsock > > see http://msdn2.microsoft.com/en-us/library/ms740506.aspx especially > > the IPV6_HDRINCL section. > > Windows XP SP2 seems to have limited the raw socket, see > > http://blogs.msdn.com/michael_howard/archive/2004/08/12/213611.aspx, > > but I think I should be sill OK as I'm working with UDP and I'm not > > trying to change the source address of anything. > > Does anyone have any advice on starting with raw socket programming? I > > have downloaded and am looking at Rock Saw at the > > moment(http://www.savarese.org/software/rocksaw/). Any other advice > > welcome. > > Does JavaSE or OpenJDK use raw sockets for its functionality, or does > > it do something else? I am going to start looking into this next. > > > > 3. Winpcap 4.0 beta 3 > > Haven't investigated much here. Does this run on top of winsock? Does > > anyone know can I send packets using winpcap? Network Packet generator > > (http://www.wikistc.org/wiki/Network_packet_generator) is built on > > winpcap, has anyone used this on windows? > > > > Thats my research for the moment. If you have any questions please get > > back to me. > > > > Thanks for reading, > > Cormac > > > > From cormac.mullally at gmail.com Fri Nov 23 08:22:04 2007 From: cormac.mullally at gmail.com (cormac mullally) Date: Fri, 23 Nov 2007 16:22:04 +0000 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <30f52a160711220642j20e00749xe0ffd36448f8fad9@mail.gmail.com> References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> <47458A97.8030201@sun.com> <30f52a160711220642j20e00749xe0ffd36448f8fad9@mail.gmail.com> Message-ID: <30f52a160711230822x9b6ee83he9c97b6cd3ca144d@mail.gmail.com> Hi all, I had a quick look at openJDK and i see that on windows it uses winsock2 as is expected. I also see that in some paces it tries to use Raw Sockets, Inet4AddressImpl.c and Inet6AddressImpl.c . Do you think in theory it will be possible for me to create an IPv6 packet and header and send them over the raw socket using winsock2? All help appreciated, Cormac On Nov 22, 2007 2:42 PM, cormac mullally wrote: > Hi Michael, > > I aggree it is quite specialised, but I think it would be good for > java to support this. Yes I would love to use Linux or Solaris but I > have to support windows. > > I am going to look at the internals of the openJDK now and see how it works. > > Thanks for your help so far and I will let you know how I get on. > > Best Regards, > Cormac > > > > > > On Nov 22, 2007 1:56 PM, Michael McMahon wrote: > > Hi Cormac, > > > > I don't think it's likely that Java SE will support RFC3542 in the near > > future. > > I can't say however, whether anybody is actually doing any work on > > trying to support it. > > It seems like a fairly specialised requirement, that the majority of > > IPv6 applications would > > not use. > > > > Have you looked at Linux or Solaris? I think these operating systems > > have good support > > for the advanced Ipv6 socket APIs. > > > > Hth, > > Michael. > > > > > > cormac mullally wrote: > > > Hello all, > > > > > > I'm working on a project at the moment that needs's access to the > > > "type 0 routing header" in an IPv6 packet. RFC 2292 describes a nice > > > API, which allows you access to the routing header, see > > > http://tools.ietf.org/html/rfc2292#section-8.9 > > > > > > I see that JavaSE supports RFC 2553 Basic Socket Interface Extensions > > > for IPv6, and from looking around it seems that Sun has no interest in > > > implementing RFC 3542 or RFC 2292(RFC 3542 Obsoletes 2292). > > > > > > My first question is: > > > Is there any one working on implementing RFC 3542 or RFC 2292 in the > > > openJDK project? > > > > > > My second question: > > > What are my options going forward? > > > > > > > > > I am pretty new to working on such low level stuff so any advice on > > > how I should proceed is welcome. > > > > > > I've done a bit of researching and here is a bit of a summary. I'm > > > developing on windows XP, so its mostly around how I would provide > > > this functionality on a windows enviornment, but in the end my > > > application would have to work on other major platforms. > > > > > > Firstly as some of you may know "type 0 routing header" has caused a > > > bit of controversy (see http://www.natisbad.org/ especially this > > > presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf) > > > and it seems that there is some security concerns. Does anyone have > > > any comment on this? I see some people are not happy as applications > > > have already been developed using this feature. Do you think "type 0 > > > routing header" will be disabled by default in routers and hosts? Do > > > you think a new method will be created to provide this routing > > > functionality but more securly? > > > > > > So imagining that all is well with "type 0 routing header" and I will > > > use it for my project, here are some of the solutions I have been > > > looking at for implementing this on windows. > > > 1. WinSock > > > 2. Raw Socket on top Winsock > > > 3. Winpcap 4.0 beta 3 supports IPv6 > > > > > > > > > 1. Winsock > > > Winsock does not seem to support RFC 3542 or RFC 2292. As in there is > > > no nice methods for adding routing headers as far as I can see. > > > http://msdn2.microsoft.com/en-us/library/ms738649.aspx and > > > http://msdn2.microsoft.com/en-us/library/ms738649.aspx > > > > > > 2. Raw Socket with Winsock > > > Raw Socket as far as I can see gives you acess to the header and data > > > parts of the packet. From my research this in theory seems to be > > > possible with winsock > > > see http://msdn2.microsoft.com/en-us/library/ms740506.aspx especially > > > the IPV6_HDRINCL section. > > > Windows XP SP2 seems to have limited the raw socket, see > > > http://blogs.msdn.com/michael_howard/archive/2004/08/12/213611.aspx, > > > but I think I should be sill OK as I'm working with UDP and I'm not > > > trying to change the source address of anything. > > > Does anyone have any advice on starting with raw socket programming? I > > > have downloaded and am looking at Rock Saw at the > > > moment(http://www.savarese.org/software/rocksaw/). Any other advice > > > welcome. > > > Does JavaSE or OpenJDK use raw sockets for its functionality, or does > > > it do something else? I am going to start looking into this next. > > > > > > 3. Winpcap 4.0 beta 3 > > > Haven't investigated much here. Does this run on top of winsock? Does > > > anyone know can I send packets using winpcap? Network Packet generator > > > (http://www.wikistc.org/wiki/Network_packet_generator) is built on > > > winpcap, has anyone used this on windows? > > > > > > Thats my research for the moment. If you have any questions please get > > > back to me. > > > > > > Thanks for reading, > > > Cormac > > > > > > > > From cormac.mullally at gmail.com Mon Nov 26 02:23:02 2007 From: cormac.mullally at gmail.com (cormac mullally) Date: Mon, 26 Nov 2007 10:23:02 +0000 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <30f52a160711230822x9b6ee83he9c97b6cd3ca144d@mail.gmail.com> References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> <47458A97.8030201@sun.com> <30f52a160711220642j20e00749xe0ffd36448f8fad9@mail.gmail.com> <30f52a160711230822x9b6ee83he9c97b6cd3ca144d@mail.gmail.com> Message-ID: <30f52a160711260223g2ee7b87cnd825c55c7e212dd@mail.gmail.com> Hi all, I'm continuing to look at how java implements its sockets. Just had a look at how it works for solaris and linix. Can anyone give me any information on the function JVM_Socket, It is defined in the jvm.h file, but I can't find it implementation. Can someone confirm that is it built on the POSIX interfaces? Thanks, Cormac On Nov 23, 2007 4:22 PM, cormac mullally wrote: > Hi all, > > I had a quick look at openJDK and i see that on windows it uses > winsock2 as is expected. > > I also see that in some paces it tries to use Raw Sockets, > Inet4AddressImpl.c and Inet6AddressImpl.c . > > Do you think in theory it will be possible for me to create an IPv6 > packet and header and send them over the raw socket using winsock2? > > All help appreciated, > Cormac > > > On Nov 22, 2007 2:42 PM, cormac mullally wrote: > > Hi Michael, > > > > I aggree it is quite specialised, but I think it would be good for > > java to support this. Yes I would love to use Linux or Solaris but I > > have to support windows. > > > > I am going to look at the internals of the openJDK now and see how it works. > > > > Thanks for your help so far and I will let you know how I get on. > > > > Best Regards, > > Cormac > > > > > > > > > > > > On Nov 22, 2007 1:56 PM, Michael McMahon wrote: > > > Hi Cormac, > > > > > > I don't think it's likely that Java SE will support RFC3542 in the near > > > future. > > > I can't say however, whether anybody is actually doing any work on > > > trying to support it. > > > It seems like a fairly specialised requirement, that the majority of > > > IPv6 applications would > > > not use. > > > > > > Have you looked at Linux or Solaris? I think these operating systems > > > have good support > > > for the advanced Ipv6 socket APIs. > > > > > > Hth, > > > Michael. > > > > > > > > > cormac mullally wrote: > > > > Hello all, > > > > > > > > I'm working on a project at the moment that needs's access to the > > > > "type 0 routing header" in an IPv6 packet. RFC 2292 describes a nice > > > > API, which allows you access to the routing header, see > > > > http://tools.ietf.org/html/rfc2292#section-8.9 > > > > > > > > I see that JavaSE supports RFC 2553 Basic Socket Interface Extensions > > > > for IPv6, and from looking around it seems that Sun has no interest in > > > > implementing RFC 3542 or RFC 2292(RFC 3542 Obsoletes 2292). > > > > > > > > My first question is: > > > > Is there any one working on implementing RFC 3542 or RFC 2292 in the > > > > openJDK project? > > > > > > > > My second question: > > > > What are my options going forward? > > > > > > > > > > > > I am pretty new to working on such low level stuff so any advice on > > > > how I should proceed is welcome. > > > > > > > > I've done a bit of researching and here is a bit of a summary. I'm > > > > developing on windows XP, so its mostly around how I would provide > > > > this functionality on a windows enviornment, but in the end my > > > > application would have to work on other major platforms. > > > > > > > > Firstly as some of you may know "type 0 routing header" has caused a > > > > bit of controversy (see http://www.natisbad.org/ especially this > > > > presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf) > > > > and it seems that there is some security concerns. Does anyone have > > > > any comment on this? I see some people are not happy as applications > > > > have already been developed using this feature. Do you think "type 0 > > > > routing header" will be disabled by default in routers and hosts? Do > > > > you think a new method will be created to provide this routing > > > > functionality but more securly? > > > > > > > > So imagining that all is well with "type 0 routing header" and I will > > > > use it for my project, here are some of the solutions I have been > > > > looking at for implementing this on windows. > > > > 1. WinSock > > > > 2. Raw Socket on top Winsock > > > > 3. Winpcap 4.0 beta 3 supports IPv6 > > > > > > > > > > > > 1. Winsock > > > > Winsock does not seem to support RFC 3542 or RFC 2292. As in there is > > > > no nice methods for adding routing headers as far as I can see. > > > > http://msdn2.microsoft.com/en-us/library/ms738649.aspx and > > > > http://msdn2.microsoft.com/en-us/library/ms738649.aspx > > > > > > > > 2. Raw Socket with Winsock > > > > Raw Socket as far as I can see gives you acess to the header and data > > > > parts of the packet. From my research this in theory seems to be > > > > possible with winsock > > > > see http://msdn2.microsoft.com/en-us/library/ms740506.aspx especially > > > > the IPV6_HDRINCL section. > > > > Windows XP SP2 seems to have limited the raw socket, see > > > > http://blogs.msdn.com/michael_howard/archive/2004/08/12/213611.aspx, > > > > but I think I should be sill OK as I'm working with UDP and I'm not > > > > trying to change the source address of anything. > > > > Does anyone have any advice on starting with raw socket programming? I > > > > have downloaded and am looking at Rock Saw at the > > > > moment(http://www.savarese.org/software/rocksaw/). Any other advice > > > > welcome. > > > > Does JavaSE or OpenJDK use raw sockets for its functionality, or does > > > > it do something else? I am going to start looking into this next. > > > > > > > > 3. Winpcap 4.0 beta 3 > > > > Haven't investigated much here. Does this run on top of winsock? Does > > > > anyone know can I send packets using winpcap? Network Packet generator > > > > (http://www.wikistc.org/wiki/Network_packet_generator) is built on > > > > winpcap, has anyone used this on windows? > > > > > > > > Thats my research for the moment. If you have any questions please get > > > > back to me. > > > > > > > > Thanks for reading, > > > > Cormac > > > > > > > > > > > > > From Weijun.Wang at Sun.COM Mon Nov 26 03:35:31 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Mon, 26 Nov 2007 19:35:31 +0800 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <30f52a160711260223g2ee7b87cnd825c55c7e212dd@mail.gmail.com> References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> <47458A97.8030201@sun.com> <30f52a160711220642j20e00749xe0ffd36448f8fad9@mail.gmail.com> <30f52a160711230822x9b6ee83he9c97b6cd3ca144d@mail.gmail.com> <30f52a160711260223g2ee7b87cnd825c55c7e212dd@mail.gmail.com> Message-ID: <3E804C8C-EC1B-467C-AA02-96256FCC5FBD@sun.com> It's defined in the hotspot workspace. Max On Nov 26, 2007, at 6:23 PM, cormac mullally wrote: > JVM_Socket From cormac.mullally at gmail.com Mon Nov 26 05:08:07 2007 From: cormac.mullally at gmail.com (cormac mullally) Date: Mon, 26 Nov 2007 13:08:07 +0000 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <3E804C8C-EC1B-467C-AA02-96256FCC5FBD@sun.com> References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> <47458A97.8030201@sun.com> <30f52a160711220642j20e00749xe0ffd36448f8fad9@mail.gmail.com> <30f52a160711230822x9b6ee83he9c97b6cd3ca144d@mail.gmail.com> <30f52a160711260223g2ee7b87cnd825c55c7e212dd@mail.gmail.com> <3E804C8C-EC1B-467C-AA02-96256FCC5FBD@sun.com> Message-ID: <30f52a160711260508m7bad7b7bjf2242cc6f424c128@mail.gmail.com> Hello Max, Ok i found it, in C:\openjdk\hotspot\src\share\vm\prims\jvm.cpp JVM_LEAF(jint, JVM_Socket(jint domain, jint type, jint protocol)) JVMWrapper("JVM_Socket"); return hpi::socket(domain, type, protocol); JVM_END And then for linix i found C:\openjdk\hotspot\src\os\linux\vm\hpi_linux.hpp inline int hpi::socket(int domain, int type, int protocol) { return ::socket(domain, type, protocol); } So it uses Socket.h which is part of the POSIX interfaces, is this true? Thanks, Cormac On Nov 26, 2007 11:35 AM, Max (Weijun) Wang wrote: > It's defined in the hotspot workspace. > > Max > > On Nov 26, 2007, at 6:23 PM, cormac mullally wrote: > > > JVM_Socket > > From fw at deneb.enyo.de Wed Nov 28 00:54:21 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 28 Nov 2007 09:54:21 +0100 Subject: RFC 3542 or RFC 2292 - Advanced Sockets Application Program Interface (API) for IPv6 In-Reply-To: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> (cormac mullally's message of "Thu, 22 Nov 2007 13:17:08 +0000") References: <30f52a160711220517h29815f7w483d5ee46c23ecfd@mail.gmail.com> Message-ID: <87hcj6eon6.fsf@mid.deneb.enyo.de> * cormac mullally: > Firstly as some of you may know "type 0 routing header" has caused a > bit of controversy (see http://www.natisbad.org/ especially this > presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf) > and it seems that there is some security concerns. Does anyone have > any comment on this? Any application which relies on IPv6 extension headers or IPv4 IP options will not work reliably across the Internet.