tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vince Stewart <stewart.vi...@gmail.com>
Subject Re: unwanted tcp6 protocol in tribes listener socket;
Date Mon, 11 Feb 2013 06:38:01 GMT
much appreciation for your help on this Tim,

Actually you can learn so much more when things are not working because you
come up with all possible reasons why they don't work and research widely.
I started off totally naive about sockets, IPv4/6, and Ubuntu firewalls and
have experienced quite a learning curve. In the end the problem would have
been trivial to most but not to someone coming from my start point.

The problem was that my home machine (behind a dsl modem) did not have an
IP entered in the '/etc/hosts' file; the socket on the home machine needed
to announce itself as 192.168.1.x but instead was one of two machines
addressed by 127.0.1.1 meaning the dsl could not resolve the address and
initial 'hand shake' failed. The whole process of getting tribes to
communicate remote-peer-to-peer took almost a week which made it so
gratifying to finally get it running.

thanks again,

On Mon, Feb 4, 2013 at 6:40 PM, Tim Watts <tim@cliftonfarm.org> wrote:

> On Mon, 2013-02-04 at 17:51 +1300, Vince Stewart wrote:
> > Hi Tim,
> > thanks so much for your reply
> > netstat -t -l  yields that includes:
> > Active Internet connections (only servers)
> > Proto     Recv-Q  Send-Q    Local Address                       Foreign
> > Address         State
> > tcp6       0          0              myComputerName:4000
> > [::]:*                        LISTEN
> > netstat -atn | grep -P ":4000\W"  yields (without any headings line)
> > tcp6       0          0              127.0.1.1:4000
> > :::*                          LISTEN
> >
> > re But why would you want that limitation?
> > My first aim was to send a single message from home to my VPS or vice
> > versa. When I did not succeed I have been fishing for reasons and the
> first
> > thing that struck me was that Ubuntu was reporting tpc6 but NioReceiver
> > object "clusterReceiver" had a "bind" property of type Inet4Address and
> an
> > address of 2130706689 (127.0.0.1).
> >
> > Possibly though, this is a normal IPv6 connection and I should treat it
> > accordingly. I'll give that ago tomorrow morning and keep CATALINA_OPTS
> in
> > mind as well.
> >
>
> Yes, I believe this is normal.  Looks like your system is using
> "IPv4-mapped addresses" which allows interoperability between IPv4&6
> hosts without needing two IP stacks on the IPv6 host.
>
> > Many thanks for your help.
> >
> >
> >
> >
> > On Mon, Feb 4, 2013 at 4:06 PM, Tim Watts <tim@cliftonfarm.org> wrote:
> >
> > > On Mon, 2013-02-04 at 14:39 +1300, Vince Stewart wrote:
> > > > Using Tomcat 7.0.35 embedded in Java standalone application. Java SE
> > > 1.7.0.
> > > > Ubuntu 12.04
> > > >
> > > > Hi All,
> > > >
> > > > I have an experimental class below. The aim is just to open a
> listening
> > > > port on port 4000 in the "localhost" address.
> > > > When this has run, the address for the listener is "127.0.0.1" in
> other
> > > > words an IPv4 address.
> > > > However the SocksSocketImpl object representing the real socket
> continues
> > > > to display the* useV4* property as *false*
> > > > and my Ubuntu system displays the listening socket as "tpc6".
> > > >
> > > Listening only for tcp6?  What does
> > >         netstat -atn | grep -P ":4000\W"
> > > show?
> > >
> > > Perhaps what you want is to set the java.net.preferIPv4Stack system
> > > property in CATALINA_OPTS?  Description here:
> > >
> > >
> http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html
> > >
> > > But why would you want that limitation?
> > >
> > >
> > > > I suspect there is some configuration issue somewhere and if anyone
> can
> > > > help with this, I would be most grateful.
> > > >
> > > > I have also noted that the java.nio.channels.spi.SelectorProvider
> cannot
> > > > return a Provider from loadProviderFromProperty() or
> > > loadProviderAsService()
> > > > so therefore issues *provider =
> > > > sun.nio.ch.DefaultSelectorProvider.create()*resulting in a
> > > > ServerSocketChannel that is of type
> > > > *sun.nio.ch.ServerSocketChannelImpl*
> > > > and a ServerSocket of type *sun.nio.ch.ServerSocketAdapter*. I'm not
> sure
> > > > that these are intended and may be I need a system property named
> > > > "java.nio.channels.spi.SelectorProvider" to ensure some other
> > > > SelectorProvider and therefore different ServerSocketChannel and
> > > > ServerSocket types.
> > > >
> > > > public class TribalAfiliations{
> > > >  Channel myChannel;
> > > >  private static class MyMemberListener implements
> MembershipListener{...}
> > > >  private static class MyMessageListener implements
> ChannelListener{...}
> > > >
> > > >  TribalAfiliations() throws SocketException{
> > > >  this.myChannel=new GroupChannel();
> > > >  ChannelListener msgListener = new
> TribalAfiliations.MyMessageListener();
> > > >  MembershipListener mbrListener = new
> > > TribalAfiliations.MyMemberListener();
> > > >  myChannel.addMembershipListener(mbrListener);
> > > >  myChannel.addChannelListener(msgListener);
> > > >    try{
> > > >
> > > >
> > >
> myChannel.start(Channel.MBR_TX_SEQ|Channel.MBR_RX_SEQ|Channel.SND_TX_SEQ|Channel.SND_RX_SEQ);
> > > >    /// same problem, with    myChannel.start(Channel.DEFAULT);
> > > >    }
> > > >    catch(ChannelException e){
> > > >    System.out.println(e.getMessage());
> > > >    }
> > > >  }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


-- 
Vince Stewart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message