snap host vs hostname
jjehl opened this issue · 5 comments
It could be better to keep the hostname in snap blocks (robot.local) because in case of using a zeroconf with avahi-daemon it is not possible to reach the host with the ip address (apart if you manualy set the ip to be on the same network... but users will never do).
I think someone will re-write the snap blocks to work with ws, so this could be the moment to keep the hostname in the calls.
I'm not sure to understand.
You have a case where you can't reach a computer on the local network with it's IP but you can with it's mDNS hostname ?
Multicast DNS efficiency depend on the network and the Operating System. On french schools there were lot of troubles with it, and there was something like 2-15s delay of a mDNS answer due to some security proxy servers which cannot be reach if the computer get offline.
We plan to re-write the Snap blocks with ws support, but I don't think we should change this behavior.
What I'm talking about is the case where the robot is directly plugged to the computer with no network at all. Using just an ethernet cable.
Pc : 192.168.0.x
RPI : 169.254.x.x
Snap calls are something like : http://169.254.x.x:6969 -> it doesnt't work
If snap calls could be : http://robot.local:6969 -> it works
I understand your point when robot is plugged on the official network of a school. Sure mDNS will slow down the answer. But most of time my users don't use the official school network (it never works and is very difficult to change) but use a direct ethernet connection or a dedicated wifi-router in the class room.
What I can do is to add a new pypot-snap-roboticia-blocks.xml with the hostname call. So users will be free to choose the ip or the hosname request. Agree ?
What OS do you have ?
Even with a IP in the APIPA range, it should work.
We used Snap blocks with this features for months with a direct connection and never experienced this issue.
EDIT: It is strange that you have an IP in the 192.168.X.X/24 range on your Ethernet card. Don't you have fixed an IP manual in the configuration of your network ?
OS : Win10.
Yes, IP is fixed because I have this case for school computers and it is better to not change anything in school ;-)
So if I choose DHCP, address range is in the APIPA range and it works.
But with stupid computers you can not easily change the configuration (you can just unplugged the ethernet cable...) the IP is not in the good range and it can work only with robot.local
I agree it is not a common situation and maybe I can jus make a dirty hack for this school.
We never experienced this case.
On lot of Education Nationale computers, If you unplug the Ethernet cable to use on the robot, it will be the case I explained above. The computer will try to see if the domain name is authorized throw a sort of proxy, and as the timeout is very high it is totaly unusable.
Both cases seems to have disjoint solutions, the best solution for you is to edit the "set robot host" block.