3 ms·

We only store the file on our central server if the receiving end doesn't have our app. If they have the app, we create a direct connection between both parties

by ritikm 14y ago

We only store the file on our central server if the receiving end doesn't have our app. If they have the app, we create a direct connection between both parties and transfer the file(s) directly without them ever hitting our servers.

dfc 14y ago
So you actually think this is a P2P architecture? On a related note how do you handle firewall piercing?
- catch23 14y ago
  probably with port knocking? pretty standard I would think.
  - _sh 14y ago
    Port knocking makes no sense in this situation. I think it's something more like STUN (RFC3489). http://www.ietf.org/rfc/rfc3489.txt http://www.ietf.org/rfc/rfc3489.txt
mapgrep 14y ago
That's a little disappointing, because it means your claim to have no file size limits can't really be true. What is the real limit for sending a file to someone who doesn't have the app installed? Would a 100TB transfer really work? I don't mean to be snide; I honestly hoped what was going on was that your server was only brokering the transfer, not taking a full upload. In other words, only when the recipient began the file download would sendrail begin uploading the file from my computer. In this scenario, sendrail would merely be reflecting a stream, not storing anything. So tell me if I understand correctly: If I share a document with someone who DOESN'T have sendrail, they will get the version of the file at the moment I send it. But if I share a document with someone who DOES have sendrail, they will get the version of the file at the moment they download it? In other words - peer to peer downloads get any file changes since the file was sent, but non peer to peer do not?
spartango 14y ago
Curiosity question: what happens if I disconnect my machine halfway through a direct transfer? Do you support continued download/upload (or multipart)? I guess in the case of a connection to your server, presumably the receiving party would never know that you sent them something (until a retry upload happened). It's just that in the case of a direct p2p transaction, it's quite likely that the downloading user's downstream bandwidth is low, such that the chance of a failure happening over the entire course of the longer transfer is higher.

by ritikm 14y ago

dfc 14y ago

So you actually think this is a P2P architecture? On a related note how do you handle firewall piercing?

catch23 14y ago
probably with port knocking? pretty standard I would think.
- _sh 14y ago
  Port knocking makes no sense in this situation. I think it's something more like STUN (RFC3489). http://www.ietf.org/rfc/rfc3489.txt http://www.ietf.org/rfc/rfc3489.txt

mapgrep 14y ago

That's a little disappointing, because it means your claim to have no file size limits can't really be true. What is the real limit for sending a file to someone who doesn't have the app installed? Would a 100TB transfer really work? I don't mean to be snide; I honestly hoped what was going on was that your server was only brokering the transfer, not taking a full upload. In other words, only when the recipient began the file download would sendrail begin uploading the file from my computer. In this scenario, sendrail would merely be reflecting a stream, not storing anything. So tell me if I understand correctly: If I share a document with someone who DOESN'T have sendrail, they will get the version of the file at the moment I send it. But if I share a document with someone who DOES have sendrail, they will get the version of the file at the moment they download it? In other words - peer to peer downloads get any file changes since the file was sent, but non peer to peer do not?

spartango 14y ago

Curiosity question: what happens if I disconnect my machine halfway through a direct transfer? Do you support continued download/upload (or multipart)? I guess in the case of a connection to your server, presumably the receiving party would never know that you sent them something (until a retry upload happened). It's just that in the case of a direct p2p transaction, it's quite likely that the downloading user's downstream bandwidth is low, such that the chance of a failure happening over the entire course of the longer transfer is higher.