Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Technology

Simple, Cross Platform P2P File Sharing via 802.11b? 41

Posted by Cliff from the wireless-communications-without-the-TCP/IP-hassle dept.
apago asks: "I travel alot on business and always need to exchange files with other people. We are always trying to figure out the best way to link two or more PC or Mac systems together. I carry regular and crossover cables and a small hub. Even then everyone has to configure a temp. IP address or have someone running a DHCP server. Most of these people have wireless 802.11b capability. Is there a way to share files between OSs using 802.11b without having to configure a temporary network setup? The autodiscovery and configuration of Bluetooth and ZeroConf sound like a good start. I like the easy of use of P2P apps." Does 802.11b need a TCP/IP stack to work? Could a low-profile stack, designed around ease-of-use, be used instead (all you would need to connect to the network would be the SSID, for example)?
This discussion has been archived. No new comments can be posted.

Simple, Cross Platform P2P File Sharing via 802.11b? More

Simple, Cross Platform P2P File Sharing via 802.11b?

Comments Filter:

  • Rendezvous does this (Score:3, Informative)

    by foobar104 ( 206452 ) on Monday August 26, 2002 @11:59PM (#4146085) Journal
    I know this isn't the be-all solution you're looking for, but be aware that Rendezvous does this very thing in Mac OS X 10.2. Since Rendezvous (which is just Apple's trademark for ZeroConf) is an open standard, it could in theory be implemented on any OS.

    The best part of Rendezvous, in my opinion, is the serverless name resolution for self-assigned IPs. For example, if your computer looks for a DHCP server and fails to find one, it assigns itself an IP address starting with 169.254. Every other computer is supposed to self-assign the same way. Normally, that's not useful, because you have to get IPs from every user before you can talk, but Rendezvous makes it possible to refer to those machines by name.

    At that point, any TCP-based program will work. FTP is my favorite, of course, but AppleShare over IP works just as well going Mac to Mac. I'm not sure what the Windows to Windows options are.

    Like I said, I know this isn't exactly what you're looking for, but I think it could get you close.
    • AppleShare over IP works just as well going Mac to Mac. I'm not sure what the Windows to Windows options are.

      So, regarding that little spot about the cross platform stuff, did you miss the 'cross' part? That's sort of essential to cross platform. What you've descibed is the opposite of cross platform. And then to mention how you don't know how the 'windows to windows' options are is shorthand for saying "I didn't bother to read the question, and I will answer it despite knowing nothing about cross platform solutions. But in any case, here's what worked for me in an entirely different scenario, using two machines with the same OS."
      • Idiot. Did you miss the part of my post where I said Rendezvous is an open standard, and while new, can be implemented on any platform? That's the definition of cross-platform, no?

        And you didn't swear in your post. Doesn't that mean you have to give up your nickname now?
  • if all you're trying to do is share a file, infrared is probably the easiest. Just line up the ports and bang, you're ready to go. Mac supports IrDA and it usually works fine for me. While transfer speed is slow, it sure beats the setup time.

    unfortunately, 802.11 configuration software is usually too clunky/inconvenient to be messing with often although winxp does a nice job and couple with osX 10.2 might just be easy enough.

  • IPv6 == magic bullet (Score:2, Funny)

    by Anonymous Coward
    As everyone who pays attention to smart people knows, all networking problems disappear when you install the magic IPv6. Just get on any IRC chatroom, and ask a networking question, and ask "how would I deal with this under IPv6" ? smart people will explain at length that your problem doesn't exist by definition in IPv6.

    So toss out you cross over cables and expensive wireless cards and drink the kool aid. Install IPv6 and you won't WANT those other guy's files ! (Because they are applications that only understand IPv4, of course.)

    Dumb people like me, well, let me introduce you to my null modem cable and cute little program called laplink, which apparently anticipated IPv6's functionality by a mere decade . . .
    • The parent comment definitely needs to be modded up. Magic bullet indeed. One does still look forward to how IPv6 enabled cell phones/wireless devices will be able to roam between cells without constantly having to disconnect and reconnect.

      (A NULL prize for the folks who suggest Mobile IP style tunneling from a home network for VoIPv6 calls.)
  • Every MS OS since 98 supports uPnP addressing. While it won't cure all, it will get rid of the need to set IP addresses. Just set the system to DHCP, and let it time out. It will then have a 169.254 address. Windows boxes on the same network should then also see each other as their names. Same with Mac OS. All these new protocals for easy setup simply add easier finding of resources, but the basic IP part has been there for years.
    • Windows boxes on the same network should then also see each other as their names. Same with Mac OS.

      You were correct until you got to this part. Until the advent of mDNS, it wasn't possible to make refer to other machines on a self-assigned IP net by name. You could only refer to the other machines by IP address, unless you wanted to set up host tables or DNS, which takes the "hoc" out of "ad hoc network." (Okay, not literally, but it's catchy nonetheless, and catchy trumps correct any day.)

      So if you had two machines connected via a cable, they could both self-assign the IPs, then you could ask the other guy what his IP is, and talk to him that way. Not very elegant, but it works in a pinch.
      • You were correct until you got to this part. Until the advent of mDNS, it wasn't possible to make refer to other machines on a self-assigned IP net by name. You could only refer to the other machines by IP address, unless you wanted to set up host tables or DNS, which takes the "hoc" out of "ad hoc network."

        Windows will broadcast a NetBIOS query for the address, won't it? It will in all other situations, so I don't see why APIPA would be different.

        That aside, why not use IPX/SPX or NetBEUI, both of which require no configuration?

  • Not so difficult (Score:2, Informative)

    by too_bad ( 595984 )
    Basically the P2P file-sharing that appeals to you
    is a application layer protocol which needs some sort
    of networking layer protocol underneath it. Usually
    IPv4 is that networking layer protocol and this is not
    something very transparent and hence all the ugly
    config stuff that you hate.

    But since underneath all that, there is a networking layer
    where you have broadcast media that everyone can talk over
    theoratically its possible to have the pplication layer P2P
    right on top of this. You can see something like this
    if you used the QNET under QNX OS (its a filesharing protocol
    like NFS, but can run directly on top of ethernet without IP)

    The reason why this is not mainstream (there are some sort of
    equivalents with MS windows and other OSes) is just that it has
    limited applictions and people havent really thought about it.
    It should be very easy to implement, say, under linux.
    Just ask for it :)
    • But since underneath all that, there is a networking layer
      where you have broadcast media that everyone can talk over
      theoratically its possible to have the pplication layer P2P
      right on top of this.

      Thank-you for putting this in terms other than "I am too lazy to setup IP addresses". What you describe could have interesting consequences for something like FreeNet [freenetproject.org] running on a community wireless network [personaltelco.net].

  • Forget 802.11b for causual networks; use USB CF (Score:3, Insightful)

    by leighklotz ( 192300 ) on Tuesday August 27, 2002 @01:10AM (#4146454) Homepage
    Get a $20 USB compact flash interface and use CF cards formatted as DOS FAT.
    They work on Win 98 and up, Macs, and Linux, and some other exotics as well.
    (Some old versions of Linux don't support some cheaper USB CF interfaces, but newer ones do.) For extra measure, get a PCMCIA CF card adapter; they cost about $10 new or $1 at a garage sale.
  • Windows, LanManager et al. supported a non-routable protocol called NetBEUI that was designed for the olden days when a network consisted of three computers and a lump of thin ethernet cable. Should work a treat over 802.11 although I suspect it's security leaves a lot to be desired and (like all Windows networking) the network browsing code leaves a lot to be desired.

    Linux? Probably, but it'll be a fight getting it up. Mac? Probably not.

    Dave

    • Well, NetBEUI was originally OS/2's protocol, so it may be more secure than you think. It just got killed with the Intarweb became the big thing.

      • NetBEUI was originally OS/2's protocol

        BZZZT
        NetBEUI was origionally developed by IBM to carry NetBIOS information over tokenring The NetBIOS Extended User Interface (NetBEUI) was introduced in 1985. from here [compuserve.com] obviously quite a while before OS/2 was even a dream.
      • A good protocol (I'm not passing judgement on NetBEUI here) can be implemented well or implemented poorly.

  • APIPA is your friend (Score:3, Interesting)

    by Gruturo ( 141223 ) on Tuesday August 27, 2002 @05:54AM (#4147205)
    Ever had one interface configured as DHCP but (due to DHCP unavailability) found out that it automagically picked an address in the 169.254.0.0/16 range?

    That's APIPA (Automatic Private IP Assignment) kicking in, newer M$ and Mac OSes (dunno about Linux, never had one configured at the wrong end of the DHCP protocol :-) ) automatically pick an IP from that range (with the last 2 octets derived from the MAC address, I guess), so that if you have a number of computers networked together, know nothing about IP and of course don't have a DHCP daemon running, they will just see each other, saving Microsoft and Apple customer support a phone call.

    So, provided that you have to swap files only between Win98+, 2000/XP or MacOS, just leave everything on DHCP and in a couple minutes the windows boxes happily start spamming out advertisement SMB packets and will eventually see each other.

    My 0.02
    • It's a GOD DAMN HEADACHE.

      If a machine failes to get a DHCP address and the machine is not assigned a static address (and in no other way is it assigned an address from another machine) it has NO GOD DAMN BUSINESS ASSIGNING ITSELF ONE.

      Although in this case it might be handy, in most cases it means that if you have a network problem the problem is masked when machines on your network can see each other, but not servers, etc. (Because your DHCP server is fucked and no machines are getting new address').

      • dumbass the address space is specifically allocated for this purpose and the manner in which it chooses an address is written in an RFC, if you don't like it design your own damn protocol and get someone to adopt it.

        • The default behaviour of having such a function enabled is stupid. It encourages bad networking.

          What happens when the DHCP server goes down? You still get a bloody IP address. You shouldn't.

          Also, for those who think it will be good for an adhoc network, well, it might be ok, but you may get conflicts when a new machine enters the zone and already had an address.

          oops.
          • What happens when the DHCP server goes down? You still get a bloody IP address.
            Your machine knows it's not a proper address though, and keeps trying to get a new one. And it does return a fairly valid error if you try to reach another machine by IP address which is unreachable.
            you may get conflicts when a new machine enters the zone and already had an address
            Yes, that would be a problem.

            Admittedly it's very confusing if you don't know it's happening... but then, you do need *some* address to use as the source address for DHCP requests, and it's better to use something from a range which doesn't stomp on any other network.

            Adhoc networks would be better running IPv6, pity there's no Windows based file-sharing stack for it yet...

            • but then, you do need *some* address to use as the source address for DHCP requests, and it's better to use something from a range which doesn't stomp on any other network.

              Not an IP address you don't dhcp works off ARP, which is why you need one of three things to get an DHCP address, a local DHCP server, arp forwarding, or a DHCP helper on the local subnet.
            • No, that is NOT how DHCP works. No source address is required.

      • It's a GOD DAMN HEADACHE.

        Why? There are lots of reasons, already discussed elsewhere, why this is a good thing. Can you give one reason why it isn't, please?

        If a machine failes to get a DHCP address and the machine is not assigned a static address (and in no other way is it assigned an address from another machine) it has NO GOD DAMN BUSINESS ASSIGNING ITSELF ONE.

        The people who wrote the RFC on self-assignment disagree with you. I do too, of course, but that's not important.

        Although in this case it might be handy, in most cases it means that if you have a network problem the problem is masked when machines on your network can see each other, but not servers, etc.

        Wrongo. Unless, of course, you're using a network that only has IP addressing, and no name resolution. Let's say I'm on machine X, and I want to FTP to machine Y. So I type "ftp Y," and I either get an IP address from the local DNS server or from my host table. My machine tries to connect to machine Y's defined IP address, and succeeds.

        DHCP server fails. After our leases expire, machines X and Y self-assign 169.254 addresses. I sit down at X and type "ftp Y." What happens?

        Nothing happens. Because there is no way for my machine to resolve "Y" to machine Y's self-assigned 169.254 address. I get an error. I call you, say "network's fucked." You reboot the DHCP server, which had somehow been allowed to stay down so long that leases started expiring.

        Of course, if instead of typing "ftp Y" I had gotten on the phone to the guy who owns Y and asked, "What's your IP right now?" and guy Y had responded, "It's 169.254.quux.plugh," and I'd typed "ftp 169.254.quux.plugh," then I would have had no problem, and you would never have known that the DHCP server was down. Of course, if that's SOP on your network, I have to wonder why you have a DHCP server to begin with.

        In other words, if self-assigned IP addressing is a problem on your network, then you, in the role of administrator, should drop what you're doing and post haste commit hari-kiri in front of your coworkers and their families.
        • Failure modes should not be otherwise functional.

          (Note: there are reasons why DHCP leases won't get renwed that do NOT relate to the server itself crashing. Perhaps the MAC address on it is getting itself chomped at a bad switch/hub. As rare as it is, it does happen.).

          In failing to get a DHCP supplied address on a machine that is configured to work via DHCP a significant error has occured.

          Would you intentionally run a network using the scheme for APIPA? I wouldn't. It is a nightmare with more potholes than any it is supposed to solve.

          Tell me, when you can't print to your printer, does windows RANDOMLY find a printer with similar functions and print there instead?

          That would be dumb. So is self assigning an address to a machine in an environment where it is defined as DHCP. Give me a configuration option that says: NEVER SELF-ASSIGN ADDRESS and I'll quit bitching about it. (And no, Registry tweaks don't count).
          • Failure modes should not be otherwise functional.

            That's about the dumbest statement of policy I've ever heard. Are you saying that all failures should be catastrophic failures? I can only assume that you were insufficiently caffeinated when you wrote this.

            Would you intentionally run a network using the scheme for APIPA?

            Matter of fact, I have. It's pretty pointless without mDNS, but now that Jaguar has mDNS support, self-assignment makes for easy ad hoc IP networking.

            Tell me, when you can't print to your printer, does windows RANDOMLY find a printer with similar functions and print there instead?

            Faulty analogy. When self-assigning an IP address, your computer doesn't actually do anything. It just configures its network ports and stops. That's all.

            Give me a configuration option that says: NEVER SELF-ASSIGN ADDRESS and I'll quit bitching about it.

            What is this, a hostage situation? "Stop self-assigning IP addresses and I'll let the nuns and orphans go, copper!" For crying out loud.
            • The failuremode of automatically self-assigning an address is virtually useless. Even if you like the functionality on your own network it is an Intentional Decision, not a passive one.

              As a developer I am tired of software and hardware which puts itself into a mode where it is almost functional but downright useless.

              If it is useless it is a catastophic failure.
              If a machine cannot access the network it was defined on then the only access available to that machine should be local sign-on. Nothing more.

              • All you're doing is repeating yourself. You haven't actually made your case at any point.

                You really ought to read this [zeroconf.org] before getting your panties (even more) in a wad about the whole thing. Summary: people smarter than us have excellent reasons for believing it's a good thing.

  • Ad Hoc (Score:1, Offtopic)

    by theNote ( 319197 )
    If they all have 802.11b, I would check out the AdHoc configurations as opposed to infrastructure which requires an access point.
    All WiFi cars I have seen support it.
    It lets you just connect directly to other devices.
    (IIRC, you all just set to the same SSID)

    I would say a TCP/IP stack is a must.

    As for the file sharing, run a light weight webserver on your machines.
    Drop whatever you want to share into the appropriate folder and voila, cross platform file sharing.
  • As someone else up there said, burn CDs or just get yourself some flash cards and a USB card reader. It's a whole lot easier to install a USB storage driver on the occasional PC than it is to set up an ad-hoc network, at least until Apple's Rendezvous shows up in Windows and Unix.

    Too much data to transfer via flash cards? I gather that it isn't because you're willing to use 802.11b, which is no faster than USB. Even so, if you really need the speed, get a Firewire PC Card and a matching portable hard drive. Macs can mount PC-formatted ones just fine. Again, carry around a floppy with the necessary Windows Firewire card drivers just in case, or better yet, jot down the URL for getting it via the Web.

    It's not glamorous, and it sure would be nice if 25 years into the personal computing era simple things like spur-of-the-moment peer-to-peer data transfer were easy to do, but it'll get the data moved without too much hassle.
  • Get one of those very small (and yes somewhat expensive) USB drives. You can purchase them without the need of a driver and of course it is universal. I always have one on me. That is way easier than any networking aggrevations.

Slashdot Top Deals

"When the going gets tough, the tough get empirical." -- Jon Carroll

Close