rosjava / zeroconf_jmdns_suite

Java implementation for auto-discovery with zeroconf.

RosJava

Metapackage for the official rosjava repositories.

See the rosjava_core readme for more details.

zeroconf_jmdns_suite's Issues

Remove ros debugging

Remove this from the pure c++ library part of the zeroconf_avahi module.

Upgrade to use ros android

Need to switch back to using standard ros android once their build environment is compatible with sdk15.

Multiple interfaces confuse jmmdns

To reproduce:

1. A computer with ip4, ipv6 and two interfaces (e.g. eth0 and tap0)
2. avahi-publish -s ConcertMaster _ros-master._tcp 8883
3. java -jar jmdns-3.4.2.jar -listener

[+] NetworkInterface: fe80:0:0:0:224:1dff:fe23:91c9%2
      Adding service listener '_ros-master._tcp.local.'
[+] NetworkInterface: 192.168.10.204
      Adding service listener '_ros-master._tcp.local.'
[+] NetworkInterface: 192.168.1.3
      Adding service listener '_ros-master._tcp.local.'
[+] NetworkInterface: fe80:0:0:0:7c13:7ff:fe61:5d5a%5
      Adding service listener '_ros-master._tcp.local.'
[+] Service         : DudeMaster._ros-master._tcp.local.
[+] Service         : DudeMaster._ros-master._tcp.local.
[+] Service         : ConcertMaster._ros-master._tcp.local.
[+] Service         : ConcertMaster._ros-master._tcp.local.
[+] Service         : DudeMaster._ros-master._tcp.local.
[+] Service         : DudeMaster._ros-master._tcp.local.
[+] Service         : ConcertMaster._ros-master._tcp.local.
[+] Service         : ConcertMaster._ros-master._tcp.local.
************ Discovered Services ************
************ Discovered Services ************
Service Info:
  Name   : DudeMaster
  Type   : _ros-master._tcp.local.
  Port   : 8830
  Address: 192.168.1.3
  Address: fe80:0:0:0:224:1dff:fe23:91c9
Service Info:
  Name   : ConcertMaster
  Type   : _ros-master._tcp.local.
  Port   : 8883
  Address: 192.168.1.3
  Address: fe80:0:0:0:224:1dff:fe23:91c9
************ Discovered Services ************
Service Info:
  Name   : DudeMaster
  Type   : _ros-master._tcp.local.
  Port   : 8830
  Address: fe80:0:0:0:224:1dff:fe23:91c9
  Address: fe80:0:0:0:7c13:7ff:fe61:5d5a
Service Info:
  Name   : ConcertMaster
  Type   : _ros-master._tcp.local.
  Port   : 8883
  Address: fe80:0:0:0:224:1dff:fe23:91c9
  Address: fe80:0:0:0:7c13:7ff:fe61:5d5a
************ Discovered Services ************
Service Info:
  Name   : DudeMaster
  Type   : _ros-master._tcp.local.
  Port   : 8830
  Address: 192.168.1.3
  Address: fe80:0:0:0:224:1dff:fe23:91c9

You can see that it doesn't catch two interfaces, and even the addresses are somewhat confused.

Fallback code for unresolved calls

Whenever a client tries to resolve an address, there should be a mechanism handling the case when that service is unresolved, thereby letting the user know that 'something is up doc'.

Jmdns ros api

Fully upgrade the jmdns implementation to use the ros api everywhere (in preference to service infos).

Duplicate names confuse jmdns

When adding a service that is already present, it will update the service name with a (2). This isn't registered back in our zeroconf class, so it's going to fall in a heap later. Particularly if we try and shutdown.

Simply python static configuration

Create zeroconf_python_avahi as a simple zeroconf node which only permits pre-configuration (can't do runtime configuration).

Check fix for multiple addresses

Confirm fix for address bug works. Ticket: http://sourceforge.net/tracker/?func=detail&aid=3399444&group_id=93852&atid=605791

If it's ok, update our source code to the latest revision.

Network interface removed callback broken

It's not getting called - no idea why.

check for listener before adding/removing it

Avoid going through avahi to do this (slow and ugly), just check internally first. Also crashes if multiply removing.

Set up zeroconf_jmdns for testing

We don't need a demo's area - can build that into the zeroconf jmdns library/jar file. But we do need that so we can easily test jmdns on the pc ( much easier than android testing).

Only worry about developing this package to zeroconf_avahi level later if we want to.

zeroconf_jmdns fails to build on Kinetic

It looks to be the same issue with gradle version as rosjava/rosjava_core#288

http://build.ros.org/view/Kbin_uX64/job/Kbin_uX64__zeroconf_jmdns_suite__ubuntu_xenial_amd64__binary/19/console

Thread protection

Potential for race conditions accessing the shared data objects in our jmdns implementation. Not going to happen much, but look into it.

Feasability of remove_listener

Not sure if this is possible, but it completes the api (review result).

Check republishing after wireless dropouts

Make sure that the avahi publisher implementation republishes after a wireless dropout.

Build working example up to publisher

Take the current working example and upgrade it to a full publisher api.

Ros Review

Wait for stack structure to be rediscovered, write up some stack documentation and propose the review to ros community.

Feedback to jmdns author

It would be really nice to flesh out the jmmdns interface more so we don't actually need our own custom network topology listener. Because we do, we're not really using the jmmdns add/remove functions. Should give the jmdns guy some feedback on this.

Embedded avahi client

Should be fairly easy to do very similarly to the generic avahi daemon. Most of the structures and api are the same, you just need to configure your own server.

Tutorials

• Zeroconf'ing ros master
• Zeroconf'ing a different service

mutex deadlocks in avahi lib

Found a mutex deadlock issue in the avahi lib - pairing mutexes inside each other is bad.

Scan over the rest and find them before they happen.

Signalling lost connection confusion

Could get into trouble if up/down alot and also sometimes forcibly removing the connection (we're signalling from both the resolver and from the avahi browser callbacks). Need to really road test.

Parameterise

Should probably do this, like the zeroconf avahi - but if we do, should probably split up the library and the ros interface like avahi as well.

Road test in huey's app manager

The road test!

It does publishing/listening and also has a wireless up/down connection, so its a good test bed.

Stop duplicating jmdns code in android

Currently copying over all the jmdns classes from the java -> android implementations. Find a better way to do this without copying!

Segfault in zeroconf_avahi lib

Worked reliably, then started getting a segfault on system startup (reliably). When I commented out the logging lines on and following line 610 in zeroconf.cpp, I saw no more instances. Debugged using the gdb launch-prefix in roslaunch.

Backtrace:
[Switching to Thread 0xb4f91b70 (LWP 31296)]
0x003784e3 in std::basic_ostream<char, std::char_traits >& std::operator<< <char, std::char_traits, std::allocator >(std::basic_ostream<char, std::char_traits >&, std::basic_string<char, std::char_traits, std::allocator > const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb) backtrace
^CQuit
#0 0x003784e3 in std::basic_ostream<char, std::char_traits >& std::operator<< <char, std::char_traits, std::allocator >(std::basic_ostream<char, std::char_traits >&, std::basic_string<char, std::char_traits, std::allocator > const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1 0x002dadf4 in zeroconf_avahi::Zeroconf::resolve_callback (

resolver=0x8087ac8, interface=3, protocol=0, event=AVAHI_RESOLVER_FOUND, 
name=0x2e957b "][", type=0x808a6e8 "_ros-master._tcp", 
domain=0x8084558 "local", host_name=0x808b1b8 "\001", address=0xb4f90c5c, 
port=0, txt=0x0, flags=0, userdata=0xbfffeef8)
at /home/user/<REDACTED>/zeroconf_implementations/zeroconf_avahi/src/lib/zeroconf.cpp:610

#2 0x008cdfbb in avahi_service_resolver_event ()

from /usr/lib/i386-linux-gnu/libavahi-client.so.3
#3 0x008c73c4 in ?? () from /usr/lib/i386-linux-gnu/libavahi-client.so.3
#4 0x00c4c441 in dbus_connection_dispatch ()

from /lib/i386-linux-gnu/libdbus-1.so.3
#5 0x008d025b in ?? () from /usr/lib/i386-linux-gnu/libavahi-client.so.3
#6 0x00c8ec37 in ?? () from /usr/lib/i386-linux-gnu/libavahi-common.so.3
#7 0x00c8f003 in avahi_simple_poll_dispatch ()

from /usr/lib/i386-linux-gnu/libavahi-common.so.3
#8 0x00c8f18e in avahi_simple_poll_iterate ()

from /usr/lib/i386-linux-gnu/libavahi-common.so.3
#9 0x00c8f356 in avahi_simple_poll_loop ()

---Type to continue, or q to quit---
from /usr/lib/i386-linux-gnu/libavahi-common.so.3
#10 0x00c8f494 in ?? () from /usr/lib/i386-linux-gnu/libavahi-common.so.3
#11 0x007bcd31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#12 0x004cd46e in clone () from /lib/i386-linux-gnu/libc.so.6

Backtrace stopped: Not enough registers or memory available to unwind further

Investigate service discovery in detail

Exactly how and what does jmdns' service discovery do? Is it useful for us?

Clean up ant builds

Clean up the build and manifest xml's and make sure they are working properly for eclipse. This will be sort of a template for our other packages.

Remove service

Need a remove service method.

Cleanup added services

Needs a shutdown method to remove activated services.

Added, resolved behaviour unexpected

Callbacks are firing strangely.

1. If you start with a service on the network, you get service 'added'
2. If you start and a service then pops up, you get service 'added'
3. If a service disappears, and then reappears, you get service 'resolved'.

remove internal list when removing listeners

It still lists discovered services of a type even after that type of listener is removed.

Avahi ipv6 upgrade

The ros api now has handles to deal with the ipv6 upgrade.

Move to it at some point.

Add service is having babies

Nothing stops it from duplicating services in some corner cases. Not sure what circumstances are prevailing yet.

Missing hydro-devel branch

Same as rosjava/rosjava_extras#5: the branch referenced by rosjava.rosinstall does not yet exist in this repo

rosjava build fails in zeroconf_jmdns_suite:Unspecified

Hi
After the recent commit I am experiencing the rosjava build fail in indigo branch stating
Could not find any version that matches org.ros.rosjava_bootstrap:gradle_plugins:[0.3,0.4)
zeroconf_jmdns_suite:unspecified
Could somebody help?

Trigger serviceRemoved callbacks when interface disappears

These make it hard for the callback style interface to work out what is going on when the network interface is removed.

User callback should fully resolve across interfaces

Should fully resolve a serviceResolved callback across all interfaces.

Currently this will only provide a ros service info with information from the one interface which triggered it. It would be good to check the other interfaces and bring all the information together, and pass that.

When an interface is dropped, that might also be a good place to trigger serviceResolved and serviceRemoved callbacks from the user - but to differentiate we need to check if it is still being served on the other interfaces first.