I have been researching proactive secret sharing for my master's thesis quite extensively. I was upset to see that no wikipedia article existed so I created one myself. Check it out!
Proactive Secret Sharing on Wikipedia
Google Code Project for DAAP Android Client
We have used Google Code Project Hosting to set up a project page for the Android DAAP client. This will hopefully keep DAAP from overriding this blog. This move also allows bugs, feature requests, and issues to be reported and well maintained. There is also a subversion repository provided by Google which will make handling commits between the two developers much easier. I hope to provide with the wiki section useful tutorials that explain some of the features, such as streaming, downloading of songs, queuing, etc. Releases will be posted there.
DAAP Android Client Updates
The first release of the DAAP client for Android had a bit more problems than I would like to admit. We have been happily working with many users to get the application to work in their situations, and in doing so, we have made the DAAP client far better than it was in its initial release. The changes below are great:
By eliminated many buffers that were created very frequently, the DAAP client is now able to handle much larger libraries. It is also easy to navigate thanks to playlist support. Queue support is nice, but the interface is probably in its beta. The auto-detection of local shares is really hit or miss and I can find no reason for it. According to a couple of android bug reports I have found, Android does not support connecting to multicast sockets, but it has worked for me a few times, but not very consistently. This is strange. Streaming will come as soon as I can find a good way to do it in Android without skips and jutters.
My main point in this post is to get feedback from the users. Is the DAAP client working for you, and if not, which server are you using? Are there any suggestions? Also, if you like the application, please rate it positively.
- Major memory optimizations
- Minor bandwith optimizations
- Automatically detect local shares
- Playlist support
- Queue support
- Rhythmbox as server support
By eliminated many buffers that were created very frequently, the DAAP client is now able to handle much larger libraries. It is also easy to navigate thanks to playlist support. Queue support is nice, but the interface is probably in its beta. The auto-detection of local shares is really hit or miss and I can find no reason for it. According to a couple of android bug reports I have found, Android does not support connecting to multicast sockets, but it has worked for me a few times, but not very consistently. This is strange. Streaming will come as soon as I can find a good way to do it in Android without skips and jutters.
My main point in this post is to get feedback from the users. Is the DAAP client working for you, and if not, which server are you using? Are there any suggestions? Also, if you like the application, please rate it positively.
DAAP Media Player released to Android Market
I am very happy to say that I have published the DAAP Media Player to the Android Market today and should be available for everyone to download! This is an initial release with many planned features to come, but I figured that everyone wanted something to use now. The application uses a heavily modified version of the Java Get It Together Client that has been stripped down to remove all GUI elements, all external libraries, and the integrated with an Android interface. The media player portion may look familiar because it is a modified version of the default Music player interface from Android.
We only have one server to test it on, but the application is known to work with a mt-daapd/firefly media server. Please comment on the functionality with other media servers. A google code project may be on the horizon. For more information on DAAP, please refer to wikipedia or my previous post.
Screenshots:
Downloads:
TOTP on Android
Time-based One-time Password Algorithm is an expansion of the HOTP algorithm that uses time as the "moving counter" instead of a normal counter. Still is draft at the time of publishing, I decided that it would not be too difficult to add this to the mOTP application that is currently in the market. A brief description of TOTP can be found on wikipedia and the full current specification here. Since I already went through the trouble of making mOTP have a multiple OTP framework, all I had to do was add a class and some error checks in the setup page. I will upload the apks soon, but they are already available on the market.
Screenshots:
Screenshots:
HOTP on Android
I have updated the Android mOTP application to support the HOTP algorithm for One-Time Passwords. This involved implementing HOTP in Java. This was not such a chore thanks to Java's easy to use security tools. However, after writing this from scratch, I realized at the end of the RFC was example source code in Java! I used this reference implementation for the android app. I did have to make a minor change to the reference implementation to support more than 10 digits of output for the generated password.
After this step was done, all that was required was to add an option to make a profile either a HOTP profile or a mOTP type, edit some database fields, and generate a new layout for the HOTP generation page. The Mobile-OTP application is translated into three languages, English, Traditional Chinese, and Simplified Chinese. A goal of mine was to have all additional strings required for this update to also be translated. I have tried very hard to make this happen.
I also wanted to implement this change in such a way that if a third OTP comes around the corner (S/Key), that change wouldn't be so hard. I didn't implement any design patterns per the Gang of Four, the code would not require that many modifications to support another algorithm.
Some screenshots for the visual people (often the first thing I look for when evaluating software):
After this step was done, all that was required was to add an option to make a profile either a HOTP profile or a mOTP type, edit some database fields, and generate a new layout for the HOTP generation page. The Mobile-OTP application is translated into three languages, English, Traditional Chinese, and Simplified Chinese. A goal of mine was to have all additional strings required for this update to also be translated. I have tried very hard to make this happen.
I also wanted to implement this change in such a way that if a third OTP comes around the corner (S/Key), that change wouldn't be so hard. I didn't implement any design patterns per the Gang of Four, the code would not require that many modifications to support another algorithm.
Some screenshots for the visual people (often the first thing I look for when evaluating software):
mDNS
I have been reading about mDNS in preparation for the DAAP client that is coming along nicely. mDNS is the component of DAAP applications that allows automatic discovery of shares on the local network. mDNS is a portion of Apple's Bonjour (formerly Rendezvous) protocol. The way that mDNS works is by essentially creating a pseudo-distributed DNS name server on the local network. Whenever a client wants to discover information about which services reside on the local network, that client creates a query to a multicast address. All machines that posses some DNS records will receive this query. The machines that has information regarding that query will reply.
JmDNS is an implementation of mDNS in Java that is very simple. They have a sample application that fetches information about the network and displays what is discovered graphically. I mimicked this code in an attempt to discover all DAAP servers on the network. I always received information that a DAAP server existed on the network, but when my application attempted to resolve the name of the server, JmDNS would never issue the callback. My application would wait indefinitely for this callback and never know how to talk to the server. This was strange to me as wireshark showed that mDNS was behaving properly and returning the address when my application was resolving the name. JmDNS was just not issuing the callback. Even more strange was the sample application included in the source would always resolve. I found a thread on the support forums at sourceforge where someone describes the same problem. They noted that the only difference between their application and the sample one was that they request was issued in a thread. Wrapping just the request for resolving a name in a thread strangely fixes the issue. I filed a bug here. Now we can move forward and incorporate the great feature of automatic server discover for DAAP into our android client.
JmDNS is an implementation of mDNS in Java that is very simple. They have a sample application that fetches information about the network and displays what is discovered graphically. I mimicked this code in an attempt to discover all DAAP servers on the network. I always received information that a DAAP server existed on the network, but when my application attempted to resolve the name of the server, JmDNS would never issue the callback. My application would wait indefinitely for this callback and never know how to talk to the server. This was strange to me as wireshark showed that mDNS was behaving properly and returning the address when my application was resolving the name. JmDNS was just not issuing the callback. Even more strange was the sample application included in the source would always resolve. I found a thread on the support forums at sourceforge where someone describes the same problem. They noted that the only difference between their application and the sample one was that they request was issued in a thread. Wrapping just the request for resolving a name in a thread strangely fixes the issue. I filed a bug here. Now we can move forward and incorporate the great feature of automatic server discover for DAAP into our android client.
Subscribe to:
Posts (Atom)
