Most NDMP folks are new to Connectathon. This is an orientation and suggested preparation.

WHAT IS CONNECTATHON?

Connectathon is an annual event sponsored by Sun Microsystems and co-sponsers who vary from year to year. It is usually held early March and lasts about a week. It's over ten years old.

Details about Connectathon are best found at www.connectathon.org.

Connectathon is not a trade show. It is not open to the public, and there are security guards to prevent non-particapants from entering the testing floor. No visitors. There is a press day, but this doesn't amount to much. There are no marketing folks, brochures, or demos.

Connectathon is very much an engineering convention. Developers of a variety of networking products gather to test the interoperability of their products. Historically, the main thrust of Connectathon is NFS (Network File System) testing. Other technologies have been added over time, including WebNFS, DHCP, and IPv6. Technologies like 100bT, Gigabit ethernet, and ATM made early appearances at Connectathon, and allowed vendors to shake-out their implementations. Connectathon-2000 adds CIFS/SMB (Microsoft File Networking), NDMP (Network Data Management Protocol), Mobile IPv4/v6, and Diameter.

Folks bring their released products, and also their unreleased products. Connectathon is an opportunity to shake-out and do a sanity check before products start shipping. Frequently bugs are found and fixed that have nothing to do with interoperability. Just the varied environment has it's benefits.

WHO ATTENDS

The participating companies reads like a who's who: Sun, SGI, IBM, Compaq (DEC), Auspex, Cisco, Hummingbird, HP, Microsoft, Apple, etc, etc. The participants themselves are the heavyweight developers. These are the folks you would just love to have access to, but don't outside of Connectathon. Most of these folks have attended Connectathon for years and know each other.

Everybody knows their stuff, so know yours. The gurus and veterans are helpful to a point. As a rule, you should have your lead developers on your Connectathon team for it to be worth your while and everybody else's. Be ready to fix your product, and be ready to commit to releasing the fix to your customers.

WHY YOU SHOULD GO

Some folks who have never been to Connectathon mistakenly say that Connectathon is too expensive, takes too long, and distracts key people. They are wrong. The alternatives cost more, take longer, are more disruptive, and have nowhere near as thorough a result.

Consider this. How much would it cost you to obtain other vendors products? How long would it take? What would it take for you to learn these other products? Do you have ready access to their gurus? Could you ever be sure you learned enough about their products and operated them correctly and thoroughly? Then, there's the flip side. Are other vendors obtaining your products? What would it take for them to learn your product? Do they have ready access to you? How much time and effort is required to support others? Do you really want others determining results with your product without your influence? Could you ever be sure they operated your product correctly and thoroughly? What about new unreleased products, yours and theirs?

Now, consider this. Sun expends hundreds of thousands of dollars on Connectathon. The Connectathon fees don't even come close to covering costs. There is a small army of key Sun engineers participating. Sun folks will tell you that if they find and resolve five bugs -- just five bugs -- it was all worth it. Why? The costs of those five bugs otherwise would dwarf what Connectathon costs Sun.

At Connectathon, you could find and resolve five bugs. It won't cost you $100ks, and it won't take months. All in all, the Connectathon fees, travel costs, and time are pennies on the dollar. It's a bargain.

You should go.

CONFERENCE HALL

The conference hall is well separated from the testing floor. The conference sessions are open to all, free of charge, and often non-particpants come by for particular sessions.

TESTING FLOOR

The testing floor is organized as rows of booths for each vendor. A booth pretty much amounts to a set of tables and chairs with low partitions on three sides. There is power along the floor and network taps hanging from the 20-foot ceiling. All network taps lead to the NOC (Network Operations Center), where the hubs, routers, DNS servers, print server, and the very nice and very capable NOC staff hang out. There is a reference Sun machine at the head of each row for all to use.

Everybody knows that there are proprietary and confidential materials just everywhere, and everybody respects each others booth space. Never go into another's booth unless there is somebody there. Never play with other people's toys.

Beyond that, the atmosphere is cordial, gregarious, and very productive. People laugh and debate all the time. Some folks bring their tunes. A few show offs bring DVDs. Don't be surprised if there are other spiffy gadgets.

Free beverages and munchies are available in the morning and afternoon. One night is a party with a nice buffet dinner and a couple of free drinks, and something fun to do.

Details about shipping are best found at http://www.connectathon.org the Connectathon web site. You'll do your own setup. When you arrive you will find a sheet with networking parameters, including your host names, your block of IP addresses, and DNS parameters.

Conference call 23-Feb --

NDMP tests, unlike most tests at Connecthon which take a few minutes, could take hours. To properly test the restore capabilities it's important for file server folks be willing and available to re-init partitions. Please have short-run tests and long-run tests available.

It's important for there to be personel in the booths. Everybody is expected to run their own equipment. Folks generally aren't allowed to enter another's booth to initiate a test.

NETWORK SNIFFING/SNOOPING

If your actual tests machines have network sniffing/snooping, don't worry about this part.

The NOC uses network switches, not hubs. This is for efficiency and not some exaggerated sense of security. The switches preclude a station from sniffing/snooping packet exhanges between two other stations. You can ask the NOC to enable specific snooping on specific ports, but this is complicated and inconvenient. If you are using a stand alone sniffer/snooper, bring your own hub and uplink it to the NOC switch. This let's you sniff/snoop all the machines on your hub.

BILLBOARD -- TEST RESULTS

Definitely bring your web browser (Netsape, IE Explorer, whatever).

The Billboard system is a web-based database for registering test machines and technolgies, and for tracking results. The Billboard only lets you see and change the results that pertain to you. You won't be able to see others.

BILLBOARD RESULTS ARE PRIVATE, ARE NOT PUBLISHED BY CONNECTATHON, NOR ARE YOU ALLOWED TO PUBLISH THEM.

Billboard is very client/server centric. For most technologies this is fine. Only DHCP has been a bit awkward, and the DHCP coordinator and participants found a way to work it. Versions and variations of protocols are usually registered as separate technologies. For example, each NFSv2, NFSv3, and WebNFS are separate "protocols", and there are client/server results for each. Each technology has a test coordinator who holds a kick-off meeting early in the week and helps participants understand the tests.

Once your equipment is set up, register your test machines and technologies into the Billboard. This lets everybody else know what you want to test. There is space for comments so you can publish necessary details. You query the Billboard to find out what tests you need to run, and the results of tests. The client-side of protocols initiates the tests, and your server-side should always be ready. After you run your client-side test, enter the result into the Billboard. There is space for comments.

BILLBOARD and NDMP

Ultimately, this is up to the NDMP tests coordinator.

I propose six "protocols" for the Billboard NDMP setup:NDMPv2-DATA, NDMPv2-TAPE, NDMPv2-ROBOT, NDMPv3-DATA, NDMPv3-TAPE, NDMPv3-ROBOT. Each protocol has obvious client/server sides.

Conference call 23-Feb --

Two additional catagories were proposed.
NDMPv[23]-COMMON represents the CONNECT/CONFIG interfaces, These may be tested using ndmjob -q.
NDMPv[23]-LOCAL means a test with DATA and TAPE in NDMP_ADDR_LOCAL mode. Unresolved question: how do we record remote DATA/TAPE interoperability.

NDMP CONTROL (client) packages should register as a client of the specific protocols supported. NDMP DATA, TAPE, and ROBOT (server) packages should register as servers of the specific protocols supported.

Examples of how test machines are registered are:

• A CONTROL package that only uses NDMPv3 and has no ROBOT control capability would register as NDMPv3-DATA and NDMPv3-TAPE clients.
• A file server without tape drive or robot and supports both NDMPv2 and NDMPv3 would register as NDMPv2-DATA and NDMPv3-DATA servers.
• A tape server without files and NDMPv2 only would registers as an NDMPv2-TAPE server, and perhaps as an NDMPv2-ROBOT server.
• A CONTROL package that does it all would register as a client of all six protocols.

Interoperability issues such as PATH indexes vs DIR/NODE indexes will be handled as comments in the Billboard. To determine whether a test result is satisfactory, and thus what result to enter into the Billboard, simply ask whether and end-user with the two packages would be satisfied -- would they be able to get their work done.

For packages that can achieve a satisfactory result with the right parameters, the result entered into the Billboard is PASSED with the parameters entered as comments.

For packages that can not achieve a satisfactory result, the result entered into the Billboard is FAILED with comments. For example, if a CONTROL and DATA package are at odds because of the type of index (PATH v. DIR/NODE), the result is FAILED. Another example, if a CONTROL and DATA package are at odds because of the type of index, yet the CONTROL package can still direct the DATA recovery without the index, the result is PASSED.

Remember, the Billboard reflects INTEROPERABILITY results, and is absolutely not a comment otherwise about a product. It simply says whether server X and client Y play nice.