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

?