Support for JEP-65''s mediating proxy?

Has there been any thought put into the possibility of the Jive messenger playing the role of this kind of SOCKS 5 proxy - used in support of bytestreams in file transfer (JEP-0065)?

Was wondering because otherwise we would need to have a seperate proxy available for this purpose. Using direct connections between clients is not an option in our usage. As I understand it, JEP-65 stipulates some extensions to the SOCKS v5 protocol, so using a standard implementation would not work.

As I understand it, there is currently only a single implementation of this special Socks proxy - the proxy65 project available in jabberstudio. Its written in Python I believe.

Another useful feature () for our usage is that the file transfer be available even when the target is offline. The server would then store the file (for a bit like what Yahoo’'s server does) until the client does come online. It would be similar to what the server does for messages when a client is offline (ie stored in something like the JiveOffline table).

Thanks!

This is a good feature request – I’'ve added it to the issue tracker as issue JM-108. Feel free to vote for it!

Regards,

Matt

Hi Matt,

We have been using file transfer on local networks but received not just positive opinions from our users. Especially when file transfer is activated/executed on low bandwidth radio network links. I would like to be flexible and allow or disallow it depending on the network type. Therefore the best would be to implement JEP-65 as plugin with options to enable/disable file transfer, limit the file size, specify SOCKS5 port.

Regards

Michael

Hi Michael,

I’'m currently working on supporting JEP-65 in JM.

It is being coded as a plugin. So far I have two file transfer ‘‘modes’’, one being a simple pipe from client to client and the other a store and forward mode with an option for a byte processor which can be used for auditing, virus scanning etc. You could also use it to limit file size. Unfortunately, the way the jep is written, the proxy has no clue how many bytes are to be transferred ahead of time. Socks jid, port and listen address are all configurable. I’'m planning on getting some jid white/blacklist support included as well.

When you say ‘‘allow or disallow it depending on the network type’’, are you looking for a white/blacklist based on ip range?

Regards,

Rob

Rob,

thanks for your quick reply.

Regarding “Allowing/Disallowing File Transfer” I would use a similar approach as s2s took

(see http://127.0.0.1:9090/server2server-settings.jsp)

Allowed to Connect

  • Anyone - Any remote server is allowed to connect to this server. Use the table below to override the default settings.

  • White List - Only some remote servers are allowed to connect to this server. Use the table below to define the allowed remote servers and their settings.


Domain | Port | Delete |

…|…|…[X]…|


Domain: … Port: …

Not Allowed to Connect

The remote servers listed in the following table will not be able to connect to this server. Use the form below to block new remote servers from connecting to this server.


Domain | Port | Delete |

…|…|…[X]…|


Domain: … Port: …

This would e.g. allow enabling file transfer for people on a local network and blocking file transfer for a community connected through a low bandwith s2s connection.

Your idea with White-/Blacklist of JIDs goes one step further.

Regards

Michael