$ cat file | nc host.example.com 8888
I don't think a dedicated utility is required.
Edit: Sorry about my comment coming off as a bit hostile, I did not intend it to be.
But that's not the point here. Sometimes you just got to make something because you want to, because it fits a specific need that maybe not a lot of other people have, or because it's a learning experience, or just for the heck of it. So, no, it's not required, but that doesn't mean it's useless.
It's cool that the author did something productive that works for him/her, and it's even cooler they shared it with everyone.
I can say that's already infinitely more than what I made today. How about you?
filename_size = 0;
memcpy(&filename_size, buf, sizeof(int));
memcpy(filename, &buf[sizeof(int)], filename_size);
I sympathize with the sentiment of "people should go out and try to create things themselves, even at the risk of failing" (or "especially" at the risk of failing), but from any objective standpoint, bcp isn't a good program. 400 lines of C to badly accomplish what 2 lines of shell can do? Someone else commented about it being very much in the unix spirit - no, I don't really think so. netcat + openssl would be in the unix spirit.
Not meant to be a criticism of the author - it's a cool project, if you don't care about certain "real-world" concerns (which isn't as unreasonable as it sounds).
I should have noted somewhere, this isn't ready for production by any means, just a first iteration of an idea I had. It is currently intended to be used on a trusted network.
Thanks for pointing this out though.
(Having spent years doing minor little things that nobody ever would care to hear about (back in the day) I can of course fully understand the positive aspects of the mental process. You learn something and perhaps people leave comments that make you feel good which spurs you on to do better things.)
Some people voted it up, I can't control that. I really could care less about karma, in fact, the critical comments (except yours) have been very useful and worth the post.
I am just being part of a community.
I now see though that ncp (http://www.fefe.de/ncp/) would have probably sufficed, though it is a slightly different approach.
Sorry if you feel mislead.
hostname can be a numerical IP address or a symbolic hostname (unless the
-n option is given). In general, a hostname must be specified, unless
the -l option is given (in which case the local host is used).
I dont begrudge people reinventing the wheel, but i fully suspect this wouldn't have been written if the author knew about nc.
I appreciate the criticism though, it is always good to question the investment of time. In this case, I feel comfortable with it. Can't discount the joy of programming little things either.
I'm not saying that it's such a big hassle that we need complicated ways of avoiding it, but this is definitely a cool project that does a away with a (minor) pain point and I for one applaud the author for scratching his itches and sharing with the world, even if his hack isn't perfect.
Recipient listens on 0.0.0.0:
recipient$ nc -l 0.0.0.0 6969 > file
sender$ <file | nc 192.168.0.255 6969
sender$ <file | nc 255.255.255.255 6969
2. A very minor point, but you are still required to know (or at least specify) a the filename on the receiving end. My solution does not.
sender$ tar -c file | nc -l 12345
recipient$ nc addr 12345 | tar -x
sender$ tar -c awesome.jpg | nc -l 0.0.0.0 12345
recipient$ nc 255.255.255.255 12345 | tar -x
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
$ <file nc host.example.com 8888
$ cat foo | bar
$ <foo bar
But for the usual case where it is I/O-constrained, you can often get files across more quickly by throwing CPU at reducing the total amount of bandwidth required by, e.g., using something like bzip or pbzip:
pbzip2 < file | nc $host $port
nc -l $port | pbzip2 -d > file
Edit: Just to be clear, that'd be:
$ nc -l $port | gzip -d > $filename
$ cat $filename | gzip | nc $host $port
If you massage the discovery/rendezvous part in, it won't be nearly as simple as a single 'nc' command.
nc -l 8888 | tar xf -
tar cf - file | nc host.example.com 8888
Also, unnecessary process spawned with cat:
nc.host.example.com 8888 < file
1) The code assumes both the client and the server have the same endian. This can be issue since a uint32 is used for both the synchronization code (BCP_CODE) and the port. This can easily fixed with htonl/ntohl conversions.
2) it assumes both the client and the server define int to be the same size (may or may not be true based on compiler/processor/OS combinations). If you use stdint definitions, this typically won't be an issue.
(Again, I don't mean to bash you or this project, just to say that it shouldn't be used in the "real-world" without being looked at rather more carefully. On a locally-secure network, or in an environment where security is unimportant, it's pretty cool.)
Can do this and other related useful things, including multicast of a file to N machines in parallel. Don't let the UDP bother you: it implements retry/checksum/etc on top of datagrams.
It's been around a few years, and is probably already in your distro.
It can pipe, as well as copy files, I wrote about it some time ago:
I've added a link for udpcast to my readme as an alternative. Thanks!
The client-server arrangement is backwards though :) Typical arrangement is for the clients to do the "anyone there?" broadcast, for the servers to reply and then the client would select the server, connect to it and they would go about their business. In your case, the server connects to the client. If you re-arrange this to natural client-server order, you should be able to get rid of the fork() call and this will help with portability (not that you probably care at this point).
size = fread(&buf, 1, 100, ft)
Also, consider switching to multicast for discovery.
Good find on the fread, that is actually a "bug", should be MAXBUFLEN instead of 100.
Agreed on multicast, I will add that to do the todo.
Thanks for your feedback!
Though, this still looks more robust, thanks for the link.
bcp < filename
cat filename | gzip | bcp
bcp | gunzip > filename
Most (I won't say all) command-line apps must be explicitly told which mode to use. There's a good reason.
Cipher - none.
So "ssh with no cipher" means "people can snoop, but I can use proper auth". But rsh means "plaintext pw - or worse things if allowed".
http://ipmsg.org/index.html.en (For Windows)
http://ishwt.net/en/software/ipmsg/ (For Mac)
Something like you just drag for the extreme left of right border, and sunddenly, the file is being transferred for the other computer.
is another nice way to do this.
I actually use SimpleHTTPServer a lot for other things though, it is a great tip.
With that said, by 'quickly', I was focusing more on easiness and simplicity.
A quick article that may help you out: http://intermediatesql.com/linux/scrap-the-scp-how-to-copy-d...
This has been my experience in practice, too.
Now it makes sense. And I can see it's use, at home.