dev@jax-ws.java.net

Re: Metro/JAXWS and network packets...

From: LeRoy Hall <leroy_e_hall_at_yahoo.com>
Date: Wed, 18 Nov 2009 06:27:50 -0800 (PST)

Hey Tony,
 
I was just wondering if you ever got a resolution to this?
 
LeRoy

--- On Fri, 10/16/09, Tony Anecito <adanecito_at_yahoo.com> wrote:


From: Tony Anecito <adanecito_at_yahoo.com>
Subject: Re: Metro/JAXWS and network packets...
To: dev_at_jax-ws.dev.java.net
Date: Friday, October 16, 2009, 2:22 PM


No Problem LeRoy your questions/comments are valid ones.

Since FireFox did not have fragmentation I have like you been assuming the jvm has it's own implementaion of the OSI layer that disassembles the PDU into packets and that may be where the issue is.

I did look for the MSS (Maximum Segment Size) which can overide the MTU and in the first sync packet it is set to 1460 bytes or the same as the MTU.

Since for FireFox the packets were not fragmented I would have to say the router is not fragmenting the packets.

Just to let you know the path for the request/response/syn/ack was from the desktop through a DLink switch up to the DLink router back down the switch and to the Server where my instance of Tomcat is running. So the client/server was running on completely separate hardware. When I looked at wireshark on both ends the PDU was sent via two packets for the request and the response. They should have been one each. I saw a couple hundred bytes payload in each with offsets of 0 for the data within each packet. In other words the entire data should have easily fit in a single packet like it did for FireFox request/response.

I have no idea why the simple post for the request from the java client was not put into a single packet to begin with.

I am like you very interested in Sun's response. If it is in the TCP/IP implementation then every communication between client and server for every app I know of when it communicates with a server will be affected.
Good thing is the problem is specific to data that fits into a packet. Still I suspect people who manage stock or bank transactions using java based applications would have a very high degree of interest in what I found out.

Regards,
-Tony

--- On Fri, 10/16/09, LeRoy Hall <leroy_e_hall_at_yahoo.com> wrote:

> From: LeRoy Hall <leroy_e_hall_at_yahoo.com>
> Subject: Re: Metro/JAXWS and network packets...
> To: dev_at_jax-ws.dev.java.net
> Date: Friday, October 16, 2009, 11:58 AM
> My knowledge of networking is
> mostly acedemic, just so you don't get the wrong
> impreression.  
>  
> This makes me wonder whether or not the JVM has
> it's own implementation of TCP/IP, or if it uses what
> is installed on the OS it is running on??  Given
> your observations, and assuming that your test from Firefox
> and a JVM was on the same machine, it would seem that the
> JVM may have it's own implementation. 
>  
> I'm also wondering if the packets are leaving your
> machine fragmented, or are they arriving at the destination
> fragmented?  Like I said, I have learned that it is a
> router on the network that can fragment packets.  Could
> be that the router on your subnet is fragmenting the
> packets, which is usually done because of a setting on the
> router that sets the maximum size of a packet.
>  
> Also, there's a bit in the packet built by either
> TCP or IP (don't recall) that can prevent
> fragmentation.  Perhaps the packets from firefox are
> being sent with this bit set.  You can use Wireshark to
> intercept packets to/from your machine to investigate this
> further.
>  
> I would like to know what Sun's response is to
> your bug report. 
>  
> LeRoy
>  
>  
> --- On Thu, 10/15/09, Tony Anecito
> <adanecito_at_yahoo.com> wrote:
>
>
> From: Tony Anecito <adanecito_at_yahoo.com>
> Subject: Re: Metro/JAXWS and network packets...
> To: dev_at_jax-ws.dev.java..net
> Date: Thursday, October 15, 2009, 10:47 PM
>
>
> Hi LeRoy,
>
> I created a simple test where I used the url object to send
> a request for a small file (less than 1460 bytes) and the
> packet issue still appears. I ran it on my internal network
> to isolate the issue. Thus on one subnet I sent a request
> via Firesfox and one packet for send/recieve and then again
> with the simple java program and 2 packets for send and
> recieve.
> So the issue is not with Metro or JAX-WS and the
> request/response was not broken up for FireFox but in the
> core code for neworking for the jvm.
>
> I created a new bug in Sun's/Oracle's bug database.
> I also had a separate party confirm what I saw.
>
> Regards,
> -Tony
>
> --- On Thu, 10/15/09, LeRoy Hall <leroy_e_hall_at_yahoo.com>
> wrote:
>
> > From: LeRoy Hall <leroy_e_hall_at_yahoo.com>
> > Subject: Re: Metro/JAXWS and network packets...
> > To: dev_at_jax-ws.dev.java.net
> > Date: Thursday, October 15, 2009, 8:14 AM
> > Curious, is it really JAX-WS that is
> > fragmenting the packets, or is it an intermediary
> device on
> > the network that is fragmenting them?  I know
> that
> > routers will sometimes fragment packets when the
> network
> > they are forwarding to require smaller packets.
> >
> > --- On Thu, 10/15/09, Tony
> > Anecito
> > <adanecito_at_yahoo.com>
> wrote:
> >
> >
> > From:
>  Tony Anecito <adanecito_at_yahoo.com>
> > Subject: Metro/JAXWS and network packets...
> > To: "Metro" <users_at_metro..dev.java.net>
> > Cc: "JWSDP Dev" <dev_at_jax-ws.dev.java.net>
> > Date: Thursday, October 15, 2009, 2:36 AM
> >
> >
> > I noticed if I send a request via
> > Metro using a small object that is less than 1460
> bytes
> > (Maximm Segment Size or MTU Maximum Transport Unit
> size) the
> > data gets sent/received in two packets. If I use
> Firefox and
> > request a small html file I only get one packet.
> >
> > Any
>  idea why this is happening? It seems to double the
> > number of packets for communication. The data is not
> > duplicated in the two packets but instead is
> fragmented.
> >
> > I am using a Java Client using jre 1.6.0_16 and the
> Tomcat
> > Server hosting the web service is also using jdk
> 1.6.0_16.
> > All are Windows based OS.
> >
> > Regards,
> > -Tony
> >
> >
> >      
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> > For
> >  additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
> >
> >
> >
> >
> >
> >
> >       
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
>
>
>
>
>
>       




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net