search

n0-computer / dumbpipe

https://dumbpipe.dev
Other
107 stars 9 forks source link

`dumbpipe connect` does not close on EOF #10

Open link2xt opened 9 months ago

link2xt commented 9 months ago

On one side I do dumbpipe listen > file.txt. On the other dumbpipe connect ... < file.txt. There is no indication that file transfer finished, I expected that dumbpipe connect will close once the file is transferred. On the receiver side would also be nice to have an option to close after receiving a file, afaik ncat -k option is the reverse of this.

Generally the use case of transferring a single large file is not very well covered.

rklaehn commented 9 months ago

Currently the behaviour is to close once both directions get an EOF.

I checked with netcat, and it also does not close when one side is sending EOF by default. There is a --close option to close once you get EOF.

❯ netcat --help
GNU netcat 0.7.1, a rewrite of the famous networking tool.
Basic usages:
connect to somewhere:  netcat [options] hostname port [port] ...
listen for inbound:    netcat -l -p port [options] [hostname] [port] ...
tunnel to somewhere:   netcat -L hostname:port -p port [options]

Mandatory arguments to long options are mandatory for short options too.
Options:
  -c, --close                close connection on EOF from stdin

So you think we should have a --close option, and/or that it should be the default?

link2xt commented 9 months ago

I have tried with ncat from nmap rather than GNU netcat. ncat has no -c/--close option. Started ncat -l 127.0.0.1 5555 listener, than ncat 127.0.0.1 5555 < 1.py client. File got printed by the listener and both quit. If I start listener with ncat -l 127.0.0.1 5555 -k, then listener waits for more connections and does not quit after receiving a file.

Which default is better and whether to add --keep or --close option depends on the usecase. If we assume that users are mostly sending files and tar archives, than closing by default is better. If it is going to be used for streaming videos, logs, mails and so on then keeping the connection open by default is better.

What could also help in case connection is kept open by default - print something to stderr when one side is closed, so user knows that transfer is finished and EOF from the sender reached the receiver. It is then not a problem to ^C the receiver manually.

eminence commented 4 months ago

For me, a --close or --one-way option would be a satisfactory solution