Handle Unknown Session
While this library is great for handling file-transfer, there are other
uses of Jingle. For now what we want to do with those is forward them to
some other service that handles those, but in order to do that the
caller needs to know which stanzas those are.
So that's what this implements.
If there's a session initiate for a file-transfer, we make a session for
it and do what we already did.
If we get a session initiate that's not a file transfer, or a jingle
message for any session we don't know about, we bounce those out to our
caller. That way they can do whatever they'd like with that kind of
Complete Uploads Once They Reach Size
The spec for Jingle claims either side can terminate the session, but suggests
that the receiver should, since it knows when it's received things.
The current code expects the sender to do it, and Conversations expects the
receiver to do it, leading to both sides waiting for the other to do something.
This change on its own is insufficient to actually fix this, but it's a big
step. We pull the size information we're given out of the session
initialization and store it in a cache, similar to how other session
information is currently stored.
Then, when the socks server detects a connection, it checks to see if there's a
size recorded for this connection. If there isn't, that's fine, it just does
what it currently does, which is hope the other side will close the socket when
it's done so the EOF will unstick things.
But if there is a size listed, then when it gets to full size it now returns.
In order for this to be fixed something will need to terminate the session
after the chunks are done being read. Eventually this should live in this repo,
but for now the code lives in Cheogram as part of the handler for the file
Rather than try to fix that now, we'll do that later and just make sure we
return, so that code is able to run.
- hGet was changed to hGetSome because hGet will buffer until it gets the right
amount of bytes, or EOF
Since we're expecting the upload to hang when it's done, we need the code to
unstick so we can count the new total and realize we're done. hGetSome is
like a non-blocking hGet, but it it blocks on 0. So if there's no data, it
will wait, but as soon as there's any data it will return right away.
- If there are multiple files in the same session that would be bad, but it
seems like none of the supported clients do that. Other things already may
not work in that case