5 Replies Latest reply: Feb 17, 2012 2:56 PM by sabre150 RSS

    UDP networking

    898586
      An inner class Thread calls the receive() method of a different inner-class Thread (actually an instance of a DatagramSocketImpl) for an inbound DatagramPacket.

      The data field and the data length fields of the received packet are set(()) into another DatagramPacket being prepared for dispatch. When this is done in the called Thread, control returns to the caller, where an address is set(), as well as a port. The newly-configured packet is then send()-ed, again via the concurrent Thread.

      Before that send() of the new packet takes place, the incoming packet's credentials are requested for a System.out.println(). A recognised InetAddress is expected, as well as a recognised port. Neither of these shows, and instead the println()s display null for the InetAddress, and -1 for the port.
        • 1. Re: UDP networking
          EJP
          Obviously there is something wrong with your description. A packet which has been received contains the source address and port. A packet that has just been constructed without address:port parameters will behave as you describe. You have something back to front somewhere.
          • 2. Re: UDP networking
            898586
            Well, I wish it were that simple. (It still might be).

            'dgsImpl_In' is a DatagramSocketImpl. In dgsImpl_In reside two dgsImpl_In-constructor-instantiated DatagramPackets - 'p' and 'p_In'. These are 4, and 3-param packets respectively.

            The calling thread calls receive() in dgsImpl_In thusly :
             peerServerudp.this.dgsImpl_In.receive(peerServerudp.this.dgsImpl_In.p_In); 
            dgsImpl_In 's receive() is :
             protected   void     receive(DatagramPacket dgpi) throws java.io.IOException {
                      
                 p.setData(dgpi.getData(),0,outLength);p.setPort(30314);
                      
            }
            Control back with the caller, we expect :
             System.out.println(peerServerudp.this.dgsImpl_In.p_In.getAddress());
            System.out.println(peerServerudp.this.dgsImpl_In.p_In.getPort());
            not to produce null and -1.
            • 3. Re: UDP networking
              898586
              Just for fun, I overloaded the dgsImpl_In receive() method so:

              Caller :
               peerServerudp.this.dgsImpl_In.receive(); 
              Callee (handler) :
               protected void receive(){try{receive(p_In);}catch(IOException recioex){recioex.printStackTrace();}} 
              then prematurely killing the real method to look at its packet states :
               protected   void     receive(DatagramPacket dgpi) throws java.io.IOException {
              
              
                   
                   System.out.println(dgpi.getAddress()+"<--Inet "+dgpi.getPort()+" <--- Port "+dgpi.getData());
                   
                   System.out.println(p_In.getAddress()+"<--Inet "+p_In.getPort()+" <--- Port "+p_In.getData());
              
                   System.exit(-2);
                   
              the upshot of which were null and -1.
              Let's ignore the data.
              • 4. Re: UDP networking
                EJP
                Why are you usng DatagramSocketImpl? And why doesn't your receive method call DatagramSocket.receive()?

                I don't get this. Use DatagramSocket API properly.
                • 5. Re: UDP networking
                  sabre150
                  Moderator action : this thread is going nowhere fast so I shall lock it.