File transfers with custom profile problems

Openfire Openfire Support
1

Dear Sirs,

i have implemented file tranfers in a client by using Jep 0095 stream initiations and bytestreams jep0065 and jep 0096.

I have implemented a “custom” profile when my apps is tranferring files between them which is published through their disco info.

When i send/receive files from a client other than mine, i use the normal jep0096 file profile, but when i send files between my apps i use a “ComplexFile” profile, which supports more features (the most usefull is that it supports multipe file tranfers).

Everything works ok when my file tranfer is p-2-p.

The prolem arises when wildfire come in play in order to become the proxy server when 2 apps of mine cannot communicate point to point.

I supposed that wildfire does not check the profile of the stream initiation, as jep0095 is open for more profiles than that of jep0096 (’‘http://jabber.org/protocol/si/profile/file-transfer’’).

Now i see that wildfire rejects my stream initiations that haven’'t the standard file profile.

Is that right?

Also, if i append into the steam initiation packet an empty standard file profile element and also my ComplexFile’'s elements will Wildfire allow it to continue?

Thank you in advance!

2

Just wnated to append the wildfire error log created from the previous actions:

2006.07.11 09:14:29 [org.jivesoftware.wildfire.filetransfer.ProxyConnectionManager$1$1.run(ProxyCon nectionManager.java:112)

] Error processing file transfer proxy connection

java.io.IOException: Illegal proxy transfer

at org.jivesoftware.wildfire.filetransfer.ProxyConnectionManager.processConnection (ProxyConnectionManager.java:190)

at org.jivesoftware.wildfire.filetransfer.ProxyConnectionManager.access$100(ProxyC onnectionManager.java:38)

at org.jivesoftware.wildfire.filetransfer.ProxyConnectionManager$1$1.run(ProxyConn ectionManager.java:109)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

3

Hey Mayprog,

Hmm I have an inkling I know what is going on on the server side. By default, the proxy attempts to link all file transfers to a JEP-0096 exchange that has gone through the server. Why did we do this you might ask? Well, it was mostly a server administration decision we don’'t want random users on other servers being able to transfer a file through Wildfire.

This feature is configurable. Set the jiveProperty “xmpp.proxy.transfer.required” to false and the proxy server will no longer attempt to match the transfer.

I am curious to know more about your custom profile? Does it do anything else beside allow for multiple files?

Thanks,

Alex

4

Alex thanks,

i am not sure if i figured it out well, but from what i understood, my app will work if i disable xmpp.proxy.transfer.required option,but in that case wildifre will act as a SOCKS5 server for everyone attempted to use it?

Our server some time will be opened to the public and in that case could it be a serious problem?

Please corect me if i am wrong.

About my “Complex File”, basically it as collection of simple files, with each file having almost the same attributes as the original jep0096 files info. These files has some more info in order to be able to support resume(in order to recognize that the files are the same that was initially sended - hash is not a perftect solution for me because if someone sends say 5000 files with 2GB data, it is a big overhead to compute a hash key… for each file).

Also, “ComplexFile” has a Preview Image.

I “invented” the ComplexFile becawse i didn’'t want to create stream initiations for each file (overwhelming overhead),i wanted all the files to travel from the same stream.

Thanks for the reply,

i will check this option of wildfire as soon as possible.

5

I don’'t think it will be a serious problem for your server. Most of the other SOCKS5 file transfer proxy implementation I know of have no such concept, so jive is unique in this regard. If you are still concerned about it there is some other action you can take by modifying the Wildfire source to perhaps check the JEPs of the users to see if they are local.

Thanks,

Alex