Hi again!
Welcome to my second blog entry about my Bachelor Thesis/Praktikum Distributed Clipboard. I´ve spent the last few days designing and setting up the the communication part of the program. I´ve implemented my own UDP-Discovery, which seems to works pretty nice, although there´s still a major bug regarding the detection of the broadcast address of the underlying network.
Furthermore I´ve decided not to implement a simple message-send feature. My Distributed Clipboard will provide a standard chat-gui which users are used to, like the one from Skype, ICQ and so on. The chat uses standard best-practice TCP thread-based socket communication. So, regarding the requested functionality, the things I still have to implement are:
- file-sharing (FileWriter, FileReader, communication)
- a new GUI, since I am still working with a prototype, until all functionality is completed
- Drag&Drop from OS filesystem to GUI and vice versa
- fixing this damn broadcast detection bug Image may be NSFW.
Clik here to view.
Lets get into more detail now: In todays blog-entry I want to present the UDP-Discovery and the aforementioned bug to you. Basically my broadCast-discovery works as follows: The application´s UDP-Listener runs on a fixed port, that can be managed via a .properties file. Using this method, I assure, that the programm will run during deployment (since I´ll ask for a not-used port Image may be NSFW.
Clik here to view.
), but it can also be changed later without having to change something in the code itself.
During Start-up, a TimerTask in combination with a Timer objekt is created. It periodically sends packages, only containing the username of the currently logged in OS user to the broadcast address if the underyling network. The ip address, which is important for further communication, is of course already contained in the packet, and does not need to be sent along seperately. The Listener gets the information out of the received packets and stores it in an obervable map, which is connected to the GUI through an observable list: any changes, that are new user registrations or registered user disconnections (over udp packeges), are stored in the map. I attached a mapChangeListener to it, which, in case of changes, writes or deletes the username to an instance of JavaFX.Collections.ObservableList. This Class is used by the ListView Object in JavaFX to dynamically set the content of the GUI.
Here´s the snippet with which i try to detect the broadcast address: http://pastebin.com/m1VQH1ki
In short, I iterate over the various installed Networkcards and write their broadcast address, if they have one, in a list which is returned then. The Function getBroadcast() “returns an InetAddress for the brodcast address for the InterfaceAddress. Only IPv4 networks have broadcast address therefore, in the case of an IPv6 network, null will be returned.” (API).
I´am currently developping on a Win64 based notebook, running java7 64 and javafx_b38 64. For testing, I also use my PC, running exactly the same setup. If I execute the project on the notebook directly in Eclipse, I have the following results: Using java7 I ALWAYS get 0.0.0.0 as the broadcast address. When I switch to java 1.6_U21 I get 255.255.255.255. While both results are incorrect, since I have an 10.0.0.X network at home, where 10.0.0.255 should be the correct broadcast address, the program at least works under 1.6_U21, but of course not unser j7 so far.
Now lets get a bit more freaky: If I build a runnable .jar and let in run on the notebook, I get different results every time I execute the program, even addresses like 8.0.0.0 or 141.211.X.X are detected as broadcast addresses – completely weird. But if I execute the same .jar file on my PC it always returns the correct 10.0.0.255!
Another thing, I just noticed, is, that the bug occurs only, if the computer is connected to the network via WLAN, maybe thats something I didnt take in consideration. I just tried to plug my notebook via cable to the router, and now I get the correct 10.0.0.255 also there – that´s got definitely something to do with WLAN-Network-Cards. I already contacted some colleagues, and their notebooks behave exactly the same. If someone has a hint for me, dont hide please! Image may be NSFW.
Clik here to view.
Again, stay tuned and thanks for your tuning in – next Week I will give you an introduction into my chat and file-sharing component!