Hi all,
does anyone know if there is an existing ‘‘proxy65’’ (i.e. a proxy machine that can be used for filetransfer over the interner) implementation in Java? I’'m trying to figure out what exactly is going inside such a proxy.
thanks,
Hey Coquelicot:
As of Wildfire 2.5.0 SOCKS5 Bytestream proxy support is built directly into Wildfire. You can check its source to see how its implemented, also Smack technically can act as a proxy as well.
Alex
Thanks AWenckus, I’'ll give it a try (so far I was using Wildfire 2.4.4).
PS: what more precisely do you mean by ‘‘Smack can ask as a proxy as well’’ ?
The way the file transfer protocol is written, without delving into too much detail, is that the file transfer sender can also act as the stream host or proxy, Smack has support for this.
Alex
I was looking for some support in Smack 2.1.0 (official release) but couldn’'t find it… wrote it from scratch, though and it works.
Thanks for the help, anyways!
I should’'ve mentioned that the support is currently not in the Smack release but in the nightly builds and current codebase. Glad to hear you got it working!
Alex
Hi Alex,
I didn’'t know that you are working on this code! great!
I tried it over mine (lousy) implementation and I think it works - better. Like you said, it is using proxy even when there is no real need for it (sender is acting as proxy) but I guess beside one extra TCP connection opened it is better - easier :-).
Are you planning to work more on this? today I have noticed some inconsistence in FileTransferNegotiator.java: when it’‘s generating element so I guess “list-single” is right. For my own purposes I have applied the following patches, maybe you would like to include them into your code (as I don’‘t know whether there is any other way to include attachments in this forum, I’'m pasting it directly:
-CUT HERE-
diff -Naur smack-dev-2006-03-12-original/source/org/jivesoftware/smackx/filetransfer/FileT ransferNegotiator.java smack-dev-2006-03-12/source/org/jivesoftware/smackx/filetransfer/FileTransferNe gotiator.java
— smack-dev-2006-03-12-original/source/org/jivesoftware/smackx/filetransfer/FileT ransferNegotiator.java 2006-03-12 09:30:41.000000000 +0100
+++ smack-dev-2006-03-12/source/org/jivesoftware/smackx/filetransfer/FileTransferNe gotiator.java 2006-03-15 17:05:06.434496096 +0100
@@ -282,7 +282,7 @@
throw new XMPPException(“No acceptable transfer mechanism”, error);
}
-
if (isByteStream && isIBB && field.getType().equals(FormField.TYPE_LIST_MULTI)) {
-
if (isByteStream && isIBB && field.getType().equals(FormField.TYPE_LIST_SINGLE)) {
return new FaultTolerantNegotiator(connection, byteStreamTransferManager, inbandTransferManager);
}
else if (isByteStream) {
@@ -427,7 +427,7 @@
private DataForm createDefaultInitiationForm() {
DataForm form = new DataForm(Form.TYPE_FORM);
FormField field = new FormField(STREAM_DATA_FIELD_NAME);
-
field.setType(FormField.TYPE_LIST_MULTI);
-
field.setType(FormField.TYPE_LIST_SINGLE);
if (!IBB_ONLY) {
field.addOption(new FormField.Option(BYTE_STREAM));
}
diff -Naur smack-dev-2006-03-12-original/source/org/jivesoftware/smackx/filetransfer/Incom ingFileTransfer.java smack-dev-2006-03-12/source/org/jivesoftware/smackx/filetransfer/IncomingFileTr ansfer.java
— smack-dev-2006-03-12-original/source/org/jivesoftware/smackx/filetransfer/Incom ingFileTransfer.java 2006-03-12 09:30:41.000000000 +0100
+++ smack-dev-2006-03-12/source/org/jivesoftware/smackx/filetransfer/IncomingFileTr ansfer.java 2006-03-15 17:07:32.156512232 +0100
@@ -184,4 +184,8 @@
setStatus(Status.CANCLED);
}
-
public FileTransferRequest getRecieveRequest() {
-
return recieveRequest; -
}
}
-CUT HERE-
I have also added ‘‘getRecieveRequest()’’ method in IncomingFileTransfer.java (mind you: it’‘s not ‘‘receive’’ but ‘‘recieve’’ because I wanted to stay in sync with your way of things; I’‘m suspecting a typo but I don’'t point it with my finger ) because it was easier in my code to reject receiving file.
Also, if you plan to work more on your code: right now the default way to send the file usng filetransfer is to use (better and wider preferred) SOCKS5 bytestream. I’'m trying to implement filetransfer crossing NATs so I need to define proxy65 host used for filetransfer… how can I do it? right now FileTransferManager assumes that this host is localhostname:7777.
Also, SOCKS5 is now preferred method to send files (which is good) but it would be also nice to be able to force old IBB method (yeah, I know that we should go forward but some clients can’'t use SOCKS5 yet). Or maybe is there a easy way to force IBB over SOCKS5?
But above all – cool code, we are going to use it for sure!
Hey Coquelicot:
Thanks for the compliments. The list-multi actually isn’‘t a bug but our original intent was so that the receiver could choose several possible stream hosts. As there is no way currently via the file transfer methods to fall back to IBB, this was the solution we had come up with. That’‘s a bummer that it breaks compatibility with PSI, i’'ll have to look into it and see if we can find an adequate solution.
It would also be very helpful to define a specific host for the file transfer, this wasn’‘t implemented in the first iteration as we were trying to make it as simple as possible and just work. Have you considered using the proxy support that is now built into Wildfire? That way your end-users don’'t have to worry about setting up their NAT properly.
IBB was a nice idea in the beginning but I’'ve found that from an implementation stand point it is horribly unreliable, the amount of data it generates even for a moderately sized file is huge and has the ability to cripple a machine. In that regard, I think its best left as a backup protocol, if that.
Hey Coquelicot:
(cut)
It would also be very helpful to define a specific
host for the file transfer, this wasn’'t implemented
in the first iteration as we were trying to make it
as simple as possible and just work. Have you
considered using the proxy support that is now built
into Wildfire? That way your end-users don’'t have to
worry about setting up their NAT properly.
I tried to use it with version 2.5.0 but it didn’‘t work on my private network (I’‘m not sure if I’‘m doing it all right BTW; I’'ll try tomorrow with version 2.5.1 and some client that supports proxy65 method).
IBB was a nice idea in the beginning but I’'ve found
that from an implementation stand point it is
horribly unreliable, the amount of data it generates
even for a moderately sized file is huge and has the
ability to cripple a machine. In that regard, I think
its best left as a backup protocol, if that.
I think you’'re right, IBB should be used as ‘‘last resort’’ option.