Guaranteed Transmission Protocols For Windows? 536
Michael writes "Part of our business at my work involves transferring mission critical files across a 2 mbit microwave connection, into a government-run telecommunications center with a very dodgy internal network and then finally to our own server inside the center. The computers at both ends run Windows. What sort of protocols or tools are available to me that will guarantee to get the data transferred across better than a straight Windows file system copy? Since before I started working here, they've been using FTP to upload the files, but many times the copied files are a few kilobytes smaller than the originals."
UDP. (Score:5, Funny)
Re:UDP. (Score:5, Funny)
TCP is so horrible. I wish HTTP used UDP by default so I wouldn't have the pro
Z-Modem FTW! (Score:5, Insightful)
Crappy connection? Resumable transfers? Slow connections? Sounds like the good old BBS days!
Z-modem is your answer.
Re: (Score:3, Informative)
UDP is actually a great basis for accelerated file transfer. Several file transfer utilities / protocols have been built around it. I deal with really large files, but I have been using Aspera on several projects with great success. Worth a look.
http://www.asperasoft.com/ [asperasoft.com]
Re: (Score:3, Insightful)
TCP does this pretty well on 99% of the internet *and* the internet is aware of TCP. Its only very "different" connections that things can make a real difference. AKA the microwave link. Though we have wrapped the link with specific hardware/software layer that lets I
Re:UDP. (Score:5, Funny)
Now I know the sound of packets being dropped. Thanks.
Any encrypted transmission protocol actually (Score:5, Informative)
SFTP should do since the communications are encrypted, if something changes along the way it should be rejected by the other end. HTTPS and any other protocol-over-SSL should do.
FTP is a plain-text protocol so if something changes along the way it won't give you any issues.
Re: (Score:2, Troll)
I don't know SSH (which SFTP uses) well enough to say that you're wrong, but I think you are. Encrypting software, in itself, does not guarantee that there are no errors. It's a simple case of garbage-in-garbage-out.
On the other hand, use of SFTP in place of FTP is mandatory in this day and age. FTP sends passwords in clear; anybody using it is wearing a big red sign that says HACK ME!!!!
As for data integrity, this is not exactly new, or rocket science. Here's the magic word: checksum.
Re:Any encrypted transmission protocol actually (Score:5, Informative)
So, in short, something like SSH or any other properly encrypted communication mechanism is a great way to both secure the data from snooping (in the case of a microwave link, a VERY real problem) as well as to safeguard the data from corruption (intentional or unintentional). I sincerely hope, for the asker's sake and possibly for the country's sake, that these files he works with are trivial.
Re:Any encrypted transmission protocol actually (Score:4, Funny)
I sincerely hope, for the asker's sake and possibly for the country's sake, that these files he works with are trivial.
Well, let's see.
transferring mission critical files across a 2 mbit microwave connection, into a government-run telecommunications center
Pretty sure encryption isn't necessary.
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Poster isn't concerned about whether the data has errors. That's a problem for the data creators. He's worried about it getting screwed up in transmission, either accidentally or maliciously
Sigh. You're welcome to nitpick my prose, but would you mind doing so in a way that makes sense. Data that got screwed up in transmission can be said to have errors. And that's what I meant.
and encryption absolutely solves that issue.
How? Not all encryption algorithms break if you mung the data after it was encrypted. Do all the algorithms break if this happens? Show me where it says this, and I'll admit that encryption is sufficient.
BTW, checksum hasn't been considered a trustworthy means of ensuring data integrity for more than a decade.
Dude, you really need to start listening to how people actually talk. For more than a decade, the word "checksum" has
Re: (Score:2)
SSHFS (Score:3, Insightful)
I use sshfs file mounts for all office document file sharing and such, not just one time transfers. SSH encryption security, with the ability to open and edit files over the network. No goofing around with samba or windows file sharing. Regardless, some sort of ssh or sftp at least.
Not sure about getting it to work on windows, but there should be some options.
Re:Any encrypted transmission protocol actually (Score:5, Insightful)
Re: (Score:3, Interesting)
Using FTP ASCII mode for binary files would be increadibly stupid, but yeah, it sounds like that could be it.
Calling ftp from a .BAT script or whatever it's called in DOS and
UUCP (Score:2)
Or I guess that would be WWCP. WWJD?
TCP? (Score:5, Interesting)
Re:TCP? (Score:5, Insightful)
TCP has timeouts. The FTP client and server probably have timeouts. Eventually, some bit of the system will decide the operation is taking too long and give up. The FTP client is probably reporting an error, but if it's driven by a poor script no-one will know.
Re: (Score:2)
I think AC has the only correct response to this post. All of the people talking about CRs must not have any experience using FTP over a spotty connection, because it is quite common to run into these kinds of issues, especially on lengthy transfers.
Re:TCP? (Score:4, Informative)
You could deal with a situation like this by zipping or rarring it into multiple small files and including parity files.
http://en.wikipedia.org/wiki/Parchive [wikipedia.org]
Re: (Score:3, Insightful)
Re:TCP? (Score:4, Informative)
Re:TCP? (Score:5, Informative)
Re:TCP? (Score:5, Informative)
I used to get dropped characters and groups of characters in text files using FTP back in the 1990s and early 21st century. It seemed to be a bug in the FTP client, because it only happened when we used the Windows Explorer interface for the product. When we did command line or used the native GUI there was no problem. If you're seeing this type of a pattern where you can see that characters are missing, switch to a different FTP client or try the Windows command line FTP.
Another possibility is that the target Windows system is mimicking a Unix system, so that an ASCII transfer is stripping the CR characters from CR/LF sequences.
On the other hand, if you really want a "guaranteed delivery" with formal acknowledgment and validation, try using a secured protocol like SSH or SFTP or a messaging system like JMS with a handshaking architecture around it. There are plenty of Open Source architectures you can build around (xBus for example), but I don't know of any ready-built executables. Commercially, vendors like IBM (MQ) and Tibco have products that deal with the messaging at a similar level.
Re:TCP? (Score:5, Informative)
Because of differences between systems like Unix and Windows, where line ends are a simple newline on Unix but a CR/LF pair on Windows. Also systems like VMS which have (had) about thirteen different file formats all inherent in the file structure itself.
In other words, because all ASCII files are not represented the same way by all different operating systems.
I know that Windows uses CR/LF for line termination and *nix uses just LF. That's a very minor inconvenience at worst,
Not if you have an "ASCII" file you are trying to read on Windows that has Unix newline conventions. Try opening a newlined file with notepad, for example.
"Little standalone utilities" are really handy for small files and small numbers of files. It's really handy when you know the format the file you have is in and what it needs to be. Please tell me how you will identify a VMS fixed record file that you have just ftp'd from a VMS FTP server when it gets to your Windows system. It has NO newlines or CR/LF pairs. You might dump the file somehow and notice that the lines are all 93 characters long and then write yourself a perl script to split it up -- or you could simply tell your FTP client that you are in ASCII mode and let the FTP server/client negotiate some resulting format that your system likes. Now try that with a VMS variable length record file, where the lines are variable length, still without line endings.
FTP wasn't designed just for hobbyists who want a file or two and have the time to deal with file formats by hand. It was designed to move data, and anything that can be automated should be. "Little standalone utilities" are a pain in the ass when trying to automate something, especially when the critical information necessary to know what specific utility to use has been lost, or is completely unknown to the recipient's system. Like VMS fixed length records on Unix or Windows.
It just seems like it's not the job of a file transfer protocol to concern itself with what an independent, unrelated application can or cannot do with the file after it's transferred.
ASCII mode in FTP has nothing to do with anyone trying to tell anyone what they can or cannot do with a file after it's transferred. It's all about knowing how to deal with a hundred different ways of representing ASCII data on dozens of different operating systems and making life EASIER for people who have to do that on a daily basis.
If YOU would rather operate in BIN mode and worry about which file formats you've just downloaded and how to convert them to an ASCII representation that your software knows how to deal with, more power to you. I got tired of dealing with this the first time I had to convert a VMS "ASCII" file to Unix and I'll let FTP do it silently for me. Yes, I've dealt with users who didn't know what ASCII mode was and downloaded a zipped file in ASCII mode and it didn't work, but the time I've saved just myself not having to deal with converting crap has more than made up for the time I've spent telling them to use BIN mode.
Re:TCP? (Score:4, Interesting)
As far as I can tell, the problem is entirely unique to notepad. Every other text editor I've ever tried handles files with Unix-style newlines correctly. Since it would be trivial to fix Notepad, I can only assume that Microsoft either doesn't care at all about Notepad, or is deliberately leaving the incompatibility in place to discourage use of Unix.
Re: (Score:3, Informative)
Or they'd rather just have you use the already included Wordpad that does handle new lines correctly.
Re: (Score:3, Informative)
Who rated this "insightful"?
I'm sorry, but I've worked in this area for years. I was responsible for moving data and source files to and from Unix to DOS to VMS to OSs that are even deader than VMS, and the problem is hardly unique to "notepad". YOU may see it only in notepad because YOU only use Windows, but there are a lot of other OSs out there. If you've never worked on an OS that has structured files inherent in the filesystem, well, l
Re:TCP? (Score:4, Insightful)
I bet it is file systems with different block sizes rounding slightly differently, and an OP that does not understand.
Re: (Score:3, Interesting)
If the drives are different sizes, different filesystems, or even just set up with different cluster sizes.
(Yes, you can do that in Windows, just don't get stupid with the settings.)
He may have corrupted files, he should really check, but if a different size on different drives is the only thing he's checked, they may be perfectly fine.
Ancient History Perspective
Back in the Dos days, people were always panicking about their memory not having the exact byte value they expected. Most pe
Re: (Score:3, Insightful)
FTP, while in ASCII mode, can try to translate line endings. If the carriage returns were removed, in order to be UNIX compatible, the file size would have been reduced.
Most FTP clients allow the enabling of a binary mode which prevents the conversion from happening.
Re: (Score:2)
TCP is as reliable as borrowing a brand new Ferrari to the crack dealer on the street corner.
UDP of course, is less reliable than that. The Ferrari is rigged with a bomb.
Re: (Score:2)
Borrow is only used to refer to the act of receiving something.
Actually Lots of people who are native english speakers use borrow interchangeably with lend. It might even be a regional thing... as people in some regions have practically accepted it as normal usage.
"borrow" = borrow - "Can I borrow a pencil?"
"borrow you" = lend - "Sure I'll borrow you a pencil."
I'm not making this up.
Re: (Score:3, Informative)
Re:TCP? (Score:5, Informative)
Re: (Score:2)
It's possible the files were transferred in ASCII mode. This means that any place a '\r\n' appeared in the file, it was replaced by a '\n'. This is normally OK (and sometimes desirable) for text files, but can really cause problems with binary files. Because \r is 0x0d and \n is 0x0a, they can often appear in sequence in that in a binary file (like two pixels in an image) when they do not mean a line break.
I would recommend that the submitted check to make sure that binary mode was enabled in the FTP cli
Re:TCP? (Score:5, Informative)
While others point out, probably correctly, that the problem is probably a binary/ascii conversion, in actuality the error checking on TCP is simply not that good.
TCP uses a 16-bit checksum, so you have 1 in 65536 chance of an error packet being incorrectly validated as being correct. To make matters worse, it uses 1's complement instead of 2's complement, so 0x00 and 0xFF are indistinguishable.
Ethernet has a 32-bit, 2's complement checksum so if you're transmitting over that link-layer you're probably in good shape. But depending on that from a systems point of view seems risky.
Much better to only transfer ZIPs and check them at the other end if you only have control over the endpoints. If you can control the transmission, use a better error-correcting high-level protocol or even a forward-error correction protocol on top of TCP.
Or just use rsync.
Re: (Score:3, Insightful)
Binary verses text mode?
Lousy windows file system screwing up on one or the other end.
Sparse files.
Windows "fixing" the data during transmission.
Loss of packets, and no error checking.
Windows.
For everything else there's md5sum (Score:3, Funny)
The transmission system is irrelevant. All that matters is that you know you have received whatever was sent.
Just make sure you send a checksum and that the received file matches.
oh wait... Windows scripting...
Robocopy? (Score:5, Insightful)
Robocopy? http://technet.microsoft.com/en-us/magazine/2006.11.utilityspotlight.aspx [microsoft.com]
W
Re: (Score:3, Informative)
Re:Robocopy? (Score:5, Informative)
Yeah but that extra functionality contains things like the ability to resume a transfer, retry if things fail, and verify the files after copying.
Re:Robocopy? (Score:5, Informative)
MOD PARENT UP. Not to mention it's multithreaded, so it's not really the same as copy/paste - it's the same as a whole bunch of copy/pastes as the same time.
Why do people keep fighting the Robocopy, I'll never know.
Re:Robocopy? (Score:5, Informative)
Actually, you can specify a single file, it just has a silly syntax.
robocopy source destination file
So "robocopy c:\a c:\b myfile.txt" will copy c:\a\myfile.txt to c:\b\myfile.txt.
Re: (Score:3, Informative)
Re:Robocopy? (Score:4, Insightful)
It might be using Windows copy protocols, but it definitely is not like copy/paste. It's restartable for instance. It's way more reliable.
We have to copy large files to our office in China. FTP always fails. Windows copy via Explorer often fails, but it is also incredibly painful to do when latency is high and one is browsing over the network. Robocopy (depending on system setup) will motor through and is very persistent when there's a connection hiccup. You definitely want restartability if you copy large files are a couple of hundred MB an hour.
I'd say make sure to break the files up in to chunks if they're large. Also, run 2-4 robocopies in parallel if the latency is high as this will give better throughput. It can do funny things to Windows though (maybe other things wait on some network handle and seem to freeze until one of the robocopy processes moves on to the next file).
Also, consider doing it over a Cisco VPN. It seems to add some robustness if there is packet loss. I often had trouble access servers in the US when I was living in China due to packet loss, but no such problem over a VPN (zero packet loss, but very slow instead, which is better).
Re: (Score:2)
First, why would FTP not be the right size? The transaction was terminated prior to the upload completing. I see that too often.
Robocopy really is a great too do deal with this problem. I have around 20 remote links with unreliable connections, and robocopy is a god send.
Use a command line. 7Z the file to be transmitted into a .7Z archive. Robocopy "\\source\server\path" "\\dest\server\path" filename.7z /ipg:9 /z /r:30 /w:30 /ipg:9 says to wait 9ms between packets. I use 9000 at slow link sites to n
Use BITS (Score:5, Informative)
Background Intelligent Transfer Service (BITS) can be used to transfer files between windows servers. It is the technology behind Windows Update. We use it in our company to transfer files across a low bandwidth sattelite connection. Great thing is that it can automatically resume transfer after rebooting both machines. SharpBits offer a nice .NET API. You can find it here: http://www.codeplex.com/sharpbits [codeplex.com]
domyjobforme tag (Score:2, Insightful)
I love it! Haha... that's probably one of the better tags I've seen.
Re: (Score:3, Insightful)
Too easily thrown around if you ask me. He's not looking for anyone to set it up, he just wants some options. Isn't that what community is about?
BitTorrent (Score:5, Insightful)
rsync should do the trick (Score:5, Insightful)
hi there,
why don't you get cygwin on both the systems and then do a rsync ?
between your own network, you might want to use robocopy(http://en.wikipedia.org/wiki/Robocopy).
BR,
~A
Re: (Score:3, Informative)
ISCSI Mounted Partition on the remote... (Score:2)
Correct me if I'm wrong... (Score:3, Interesting)
Re:Correct me if I'm wrong... (Score:4, Informative)
Implementations of TCP in most operating systems fall a bit short of that, killing off stalled connections, etc. Also, some firewall suites, and some routers make a habit of killing off connections after a certain amount of time, sometimes without regard to whether or not they are 'active'.
You might have some luck boosting reliability with the TcpMaxDataRetransmissions registry setting in Windows. But ultimately, the poster is going to need to find a file copy suite which retries when connections die.
The protocol needs to be a part of the discussion (Score:3, Informative)
But I digress. What the user is running into here is a fundamental problem with TCP over lossy networks. It really was not designed with really lossy networks in mind. E.g., th
Line endings! (Score:5, Insightful)
they've been using FTP to upload the files, but many times the copied files are a few kilobytes smaller than the originals
Twenty bucks says you're converting from Windows line endings (/n/r) to Linux line endings (/n).
Use binary mode and you'll be fine.
Mod parent up (Score:2)
Line ending was my first thought too. I've used FTP scripts in Windows to and from *NIX machines with no trouble at all. I can't vouch for how well it works for Windows-Windows transfers because in that case I've always just used shared folders. That worked fine too. Unless the data is sensitive, there's really no need for scp or anything fancy.
RCP (Score:2)
it's not just for Linux.
BitTorrent (Score:2)
Re: (Score:2)
Set up a tracker on one of the servers, and have a client on both. (This may not even be required, but I'm not sure)
You also have the much more interesting property of the technology which is to automatically retransmit any faulty data, and 100% guarantee the resultant file will be bitwise identical. Furthermore, you can have the clients automatically add any .torrent files found in a specified (remote, in your situation)
First Off (Score:2)
Sneakernet (Score:2)
Probably tape drives, or hard drives if you prefer. Encrypt with a shared key. I think microwave is LOS already, so your distances can't be that large. It would certainly solve your "flaky" bandwidth and security considerations. You would "packetize" the data, eg: tapes are brought over in serial succession; if a tape went missing, you delete the key that encrypted it's contents and request a resend of the contents of that tape. That verifies it's receipt.
Not sexy, but it's probably the best solutio
Re: (Score:2)
I think microwave is LOS already, so your distances can't be that large.
I'm not sure it is the distance that matters but what is in that distance. Sneakernet probably isn't the better option if there is, say, a cliff in the middle.
Re: (Score:2, Funny)
rsync (Score:5, Informative)
... is what you want. Yes, you can use it with Windows (with or without cygwin bloat). Use -c and a short --timeout and you're good to go. If you're using it over ssh you're looking at three layers of integrity (rsync checksums, ssh and TCP), two of them quite strong even against malicious attacks not only against normal stuff. Put it in a script with a short --timeout; if anything is wrong with the link your ssh session will freeze completely, as soon as your --timeout is reached rsync will die and your script can respawn a new one (which will resume the transfer using whatever chunks with good checksum you have already transfered and will again checksum the whole file when it finishes).
Re:rsync (Score:4, Informative)
Re: (Score:2)
No mod points, but this is the answer to your question.
Confirm the data loss first (Score:2)
Take an MD5 hash of the data or something, then send it. If it comes back changed, you've got data loss. If it comes back the same, and the files are still a few kb smaller, then either you're the Wizard of File Hashes or you're reading off on-disk size instead of actual data size.
RTFM - set binary mode in FTP (Score:5, Informative)
Ritchie's Law - assume you have screwed something up *first*, before blaming the tool...
MOD PARENT UP (Score:2)
'hash' is also a nice feature...
That is to be expected (Score:2, Funny)
AS2 FTW (Score:3, Interesting)
You should look at the EDIINT AS2 protocol [wikipedia.org], AKA RFC 4130 [ietf.org]. This is a widely-used e-commerce protocol built over HTTP/S.
AS2 provides cryptographic signatures for authentification of the file at reception, non-repudiation and message delivery confirmation (if no confirmation is returned, the transfer is considered a failure), and is geared towards files. There is even an open-source implementation avaliable.
More complex than FTP/SFTP but entirely worth it if your data is mission-critical and/or confidential. Plus, passes through most networks because it is based on HTTP.
Use .complete files. (Score:4, Interesting)
Even on reliable connections, using .complete files is a great idea.
It works this way: If you're pushing, open ftp, after ftp completes, you check remote filesize, if matches local file size, you also ftp a 0 size .complete file (or a $filename.complete file with md5 checksum, if you want to be extra paranoid).
Any app that reads that file will first check if .complete file is there.
If remote file size is less, you resume upload. If remove filesize is more than local, you wipe out remote file and restart.
Same idea for the reverse side (if you're pulling the file, instead of pushing).
You can also setup scripts to run every 5 minutes, and only stop retrying once .complete file is written (or read).
Note that the above would work even if the connection was interrupted and restarted a dozen times during the transmission. [we use this in $bigcorp to transfer hundreds of gigs of financial data per day... seems to work great; never had to care for maintenance windows, 'cause in the end, the file will get there anyway (scripts won't stop trying until data is there)].
the dumb simple solution (Score:2)
How about creating SHA1 checksum and then transferring data using netcat? You could split files in pieces then run them though sha1 and finally send over netcat using udp and retransmit at will. Or if files don't change too much you could try rsync.
This is all unix-centric solutions, so you'd have to install cygwin, unless there exists a python library that does all that.
How about just going to the past? (Score:2)
Stuffit or WinRAR (Score:2)
I used to have a similar problem over another connection, where even more advanced file copy utilities would say the file was copied, but a 2-4k chunk would be missing. What I did to solve the problem was to use an archiving utility that supported adding ECC records and install it on both endpoints. Then, I'd just archive the files I need, send them over the faulty link, and usually the ECC records were able to correct any errors that did crop up during the transfer when extracted on the destination machi
linux proxy (Score:2)
Setup a linux box on the same network next to the windows box that is at the 'remote' end of the transfer (eg, not the end the transfer is initiated from).
Use ssh from the 'local' end to transfer the file to the linux box. Then run something appropriate (ftpd? apache? samba?) on the linux box that makes the files directly available to the windows box.
Alternatively, rip the Windows crap out and replace both ends with a real OS.
Bittorrent (Score:2)
I would reckon that something based on the Bittorrent protocol (or a subset of it) might be an exceptionally reliable way of, while running in the background, sending files from one machine to another one.
The protocol comes with built-in file splitting/recombination, block validation and you can get several GUIs (and I believe at least one command line implementation) for it. It might be a bit overkill though - pretty much everything in the protocol related to dealing with managing communications with multi
synchronous/asynchronous? (Score:2)
Does your file have to be transferred in-synchro?
Otherwise you might want to look into Message Oriented Middleware, things like MQ Series or in worst case scenario, even Microsoft MQ. There are plenty of options.
This would allow you to put policies on the messages, handle routing (in case you need to deliver to different recipients), guarantee delivery at least once, do type conversions/transformations etc.
You're kidding, aren't you?? (Score:5, Insightful)
You are kidding about this, aren't you?
Let me get the facts straight:
- you have "mission critical files", and the network you're transferring them over is so incredibly badly managed that it doesn't support reliable data transfer
- you want a technical workaround for this brokenness.
If this is the case, you don't have a technical problem on your hands; you have a political one.
"Mission critical" has a meaning: it means critical to the success of the operation. I.e. without these files, your operation or someone else's operation will fail.
If your management believes that your files are "mission critical", and you're facing a problem of this sort, you need to document the difficulties you're having, along with measurements to support your claims and then make a clear statement that as long as your network path is completely broken, you are absolving yourself of responsiblility for the correct transmission of these files.
If your management doesn't do anything about this, then the files are not "mission critical".
Re:You're kidding, aren't you?? (Score:4, Insightful)
Re: (Score:3, Insightful)
I think you missed the part about the government being involved
Cygwin + lpd (Score:3, Funny)
Set up a BSD lpd queue under Cygwin, something like:
sendit:lp=/spool/null:sd=/spool:if=/spool/sendit.sh:sf:sh:mx#0:
Have the sendit.sh script do whatever it is you want with the file. To send a file: lpr -Psendit filename
Configuration of the network queue left as an exercise for the student. (Hint - queue pathnames locally.)
Re: (Score:2)
I've used WinSCP before, and it seemed to be a good product.
Re: (Score:2)
The problem with FTP/SFTP/SCP is that if the connection breaks or theres other transfer errors (there will always be) and like he says, FTP does have the tendency to break files. You can solve this with checksums and transferring again, but thats not probably the most efficient solution. Something along the lines of torrent protocol would actually be perfect, as it has multiple good checksum tests and the file is partitioned, so you only need to retransfer one piece instead of whole file if its bad. Now tor
Re: (Score:2)
ZMODEM!!!!
But seriously, some of the old file transfer protocols had some pretty nifty abilities, like restarting downloads.
Re: (Score:3, Informative)
You don't need to MD5 if you're using rsync. The rsync algorithm already uses checksums to ensure the files are bit-for-bit identical. In fact, rsync 3.x uses MD5.
Re: (Score:3, Informative)
"You don't need to MD5 if you're using rsync. The rsync algorithm already uses checksums to ensure the files are bit-for-bit identical. In fact, rsync 3.x uses MD5."
Rsync, by default, does not necessarily do this. I've seen situations where rsync would happily copy files from a remote host over ssh to a destination host and the resulting files failed an independent MD5 test. Rsync was not causing this trouble - but it did fail to detect it. Forcing a checksum of every file (using "-c") would let rsync de
Re: (Score:2, Funny)
I've never heard of that product. Who makes it? Can it do binary transfers also? It must be open-source with such an odd name.
Re:Jesus protocol (Score:4, Funny)
It must be open-source with such an odd name.
Close. It's open sores, especially around the wrists.
Re: (Score:2)
Yeah, but having to drive nails through your hands and count the droplets before entering the count as a one time pad gets old after a while.
Re: (Score:3, Funny)
Not to mention the three day latency on refreshing the entropy pool.
Re:Guaranteed? Wait, What!? (Score:2)
They use FTP? Hopefully only through ipsec or something.
Re:Guaranteed? (Score:4, Funny)
Windows at both ends... Used to use FTP... Considering windows file sharing...
Is anyone else a little nervous? I hope by 'government' he means Department of Natural Resources or some equally uninteresting entity. I am picturing someone at the SEC going "You know, I swear this accounting data had a few more rows the last time I looked at it-- Oh well it's not like this Madoff guy is actually up to anything strange anyway"
Re: (Score:3, Funny)
Re: (Score:3, Informative)
Windows reports file sizes exactly, to the byte.
It reports both the true file size and the file size on the disk, which is based on the block size and the number of blocks required to store the file. ..