Presentation 1

Download Report

Transcript Presentation 1

http://www.liquidlan.net/
What is it?
• File sharing system for LANs
• extends the functionality of Windows(/Samba)
networks
• Runs on top of Windows networks
• Client-server based
• Windows client (eMule framework)
• Linux server/search engine (Seek42 fork)
• Rotting away on my hard drive
• The GUI…
The client GUI
Is this P2P?
• Sorta… was Napster P2P?
• My front-end requires centralized server.
• Client-server approach better for LiquidLan
–
–
–
–
Instantaneous search results
No need for “Internet” scalability
Highly simplified implementation (more reliable too)
Less resilient to close-minded administrations 
• However, underlying overlay network is P2P.
• SMB/CIFS use client server approach
• Network Neighborhood can be viewed as network of
peers and ultrapeers (winners of master browser
elections)
• LiquidLan doesn’t care though.
The system
Quick background
• Server Message Block (SMB)
–
–
–
–
–
Protocol used by Windows networks
Mainly file/printer sharing, IPC
MS extended it, renamed CIFS
Can run over NetBIOS or TCP/IP
Inefficient though (broadcasts to entire subnet)
• Windows networks
– SMB client and server, Network Neighborhood, etc.
– free, open source implementation called Samba
The server
The server
• Seek42
• GPL’d Windows network search engine
• Scans LANs, indexes results, answers search
queries (TCP/IP)
• Uses modified smbclient (not for long though)
• ~10,000 lines of code
• Heavily extended
• But new version just released, so I will need to
merge my changes.
The server (modifications)
•
•
•
•
•
•
•
•
•
•
•
search returns more than just exact substring matches
search creates pretty-printed stats
smbclient patch filters junk file types
tse can expire an entire class C
new ipfile syntax
optimized (struct res_t).host… now long int
dynamic data structures for run-time reconfig
added comments, documentation
configuration file (no more defs.h)
easy installation
Numerous bug-fixes
The server (TODO)
•
•
•
•
•
•
•
Merge seek42-1.0 with mine
Add opt-in support
Implement an XML-based configuration
Remove need for modified smbclient
Remove legacy code
Finish the config request handler
…
The client
•
•
•
•
•
•
•
•
•
•
No restrictive webpage interface, UNC resource paths…
A fully-functional, specialized, application client
eMule application framework (threw out core logic)
Written in Visual C++, uses MFC heavily
Heavily relies on the Windows API
So in other words, not very portable 
Multi-threaded search client and download manager
Integrated Web browser (special purpose)
Highly configurable (needs work though)
Faaassssst!
The client
• But perhaps the coolest feature of all…
• DRUM ROLL PLEASE…
DLCP
•
•
•
•
•
•
Dynamic LiquidLan Configuration Protocol
Not to be confused with DHCP ;)
Conceptually very similar though
Zero-conf solution…
Dynamically resolve server address
Dependent on database-driven program that runs on
dlcp.liquidlan.net
• LiquidLan server operators can create an account and
manage their config
• Therefore, users can install, open, and connect
automagically!
• That is my ultimate goal… complete transparency of the
underlying system (end-users don’t wanna know!)
DLCP continued...
The client (TODO)
•
•
•
•
•
•
•
•
•
Implement the initial exchange of configuration between the client
and server; this must run asynchronously (in a separate thread).
Isolate all the hard-coded policies and make them user options.
Add the “Search hard drive for media” feature which traverses the
hard drive for media to share, respecting DRM when possible***
Add an auto-update mechanism (maybe)
Add iTunes, Windows Media Player, and Winamp integration.
MBCS support (TCHAR instead of char)
Eventually add IPv6 support (maybe)
Finish DLCP!
…
Current systems
•
•
•
•
•
•
PySMBSearch
UntzUntz LAN Scan
Strangesearch
Netropolis
Phynd
None of them come equipped with a
usable application front end.
Lit Review (quickly)
• Incentives in BitTorrent Induce Free Riding
• The Impact of DHT Routing Geometry on
Resilience and Proximity
• Tree-Based ALM using Proactive Route
Maintenance
• An XML-based Conversational Protocol for
Web Services
• Design Choices for Content Distribution in
P2P Networks
Design
•
•
•
•
•
•
Design Process Model similar to Waterfall
In general, good OOP design principles
Clean frameworks!
Loosely coupled (small interfaces)
Reusable/Extendable
The waterfall…
The Waterfall
THE END
For more visit www.liquidlan.net