It is meant to use Openfire itself as a proxy, so it is not a third party. This could be a Smack issue, as in band works with Smack 3.0.0 and doesn’t work with 3.1.0/3.2.0. Spark 2.6.0 is using 3.2.0 i believe because this version had a lot of fixes of other issues. File transfer wasn’t tested in all possible scenarios and this issue hasn’t been reported while Spark was in RC phase.
The server is a third party. That’s why the spec says that IBB is allowed. This is a peer to peer network where the server acts as a facilitator not as a messaging moderator. If I, for whatever reason, don’t want the server to cache anything (server proxy off message caching off) all message traffic should still work. The server is a third party in a peer-to-peer communication and, in a good ivory tower world, should only be there for the intial addressing.
I’m not trying to be rude but I do find your answer odd and troubling from a key community member. I also don’t want Smack tied to Openfire or any XMPP server. If this is the future then I may have to look elsewhere. Is it?
I also want to note that we did pick up on this early but couldn’t for the life of us figure out what was wrong until after about a week of poking around while we worked on other features for the tool we’re developing. We figured, given the real lack of detailed documentation, that we were using it wrong. So we eventually loaded up Spark and went through the process of double checking how we did things against the Spark code…which was the same. We then tried Smack, which had worked in the past, and discovered that it didn’t work now (this was probably complicated by different versions running on different machines).
What exactly sounds troubling to you? Is it me calling the server not a third party or is it related to Smack. I’m not sure Smack is somehow tied to Openfire or any server. I think it is not, but i’m not a developer (and being a community key member is one of the side effects of living in these forums for 5 years:)). You can ask Robin Collier (current lead developer) about Smack plans. You should probably ask in the forums, or maybe even pm him, so he notices your question.
As about server. Yes, technically it is a third party. Probably bad wording from me. What i wanted to say, is that i don’t see it as a security issue if that server is my own local Openfire server. But that’s my personal opinion. I’m used to call “third party” something foreign, like service providers, public servers, public proxies.
You may use alien to install spark on debian from rpm
Hi Nicholas, any patched to fix IBB in Smack is highly welcome. Robin Collier is working on his spare time and this applies to myself too. Wolf and Holger are doing their work in Spark as part of an internship. If you are a professional developer and you want to use Smack/Spark in a project, it might be more than sensible to contribute to the project.
Complaining and asking others to fix issues that are required for projects is inacceptable. If you can figure out, why the IBB fall back is not working anymore, please provide a patch.
I’m not asking others to fix some random issue. I’m asking for regressions to be acknowledged and to be removed when they are found. This was working. A checkin moved us backward. Saying anything else is “unacceptable” and not something that I would care to teach interns to accept. If you check in bad code you go out of your way on nights and weekends to fix it. That’s just the way its done.
I also feel that this is being blown off as “not a big deal” under the false assumption that the server is part of the communication pathway which violates the spirit of the protocol. I also spent a great deal of time discovering what had happened. I take strong exception to the assumption that I’ve done nothing and am just complaining.
I’m also not the best person to roll back the change since I am not the one that changed it in the first place. I can go back to Fisheye and find said person, but I really think it better that he fix his code now that someone has pointed out the general problem since he knows what he was thinking at the time.
I need to clear something for myself. Nicholas, are your issues with IBB related to Spark or Smack? Which of them are you using for your project? Can you approximately point to a biuld/revision when it stopped working? Or was it working with the stable 2.5.8 version and now it doesnt work? Also, is it only happening in the scenario with one PC having 2 IPs (like described in the blog post)? The problem is, that if this issue was introduced more than 2-3 months ago, then it is hard to find who’s to blame. Walter, Wolf and Holger took on Spark only recently and if it is an older regression, then it is not right to blame them and push them to find “don’t know what”. So, was it introduced in the recent revisions? Or maybe this is about Smack? Then we should ask Robin Collier (or the one who was doing patches for the latest Smack version before him, wonder if we can still find him).
That’s a great question. I am hoping in the car for a three hour drive though I will follow up on Monday. Currently we usually just use the Smack API with Spark for testing or when an out of the box client will do. We have noticed that a down grade to Spark 2.5.8 works and that we likewise have to downgrade SMACK to the same equivalent version…which escapes me at the moment. I’ll get the exact rev numbers to you on Monday. I was actually suprised that I needed to downrev both sides of the pipe. The sending client does say that it can handle IBB but then in the negoitation back and forth IBB is never actually tried. I believe one of our team posted the actual communication (and if not them someone else) to the forums. I’ll double check and also dig that out.
The change was probably not introduced during the 2.6.0 dev phase. Larger code changes happend to Smack some time ago with respect to Bytestream and IBB. The related bug in Jira is Smack-338. The interns were not breaking this and they a investigating it to remove the regression.
Fixed in build 354 of Spark 2.6.0 and Smack trunk. Needs external verification
Thanks Walter. We have a release early this week. I had just started to sit down and look around when I got the update to this thread. After we get the release out I can have my team run tests in our enviornment. We should have news by Friday.
So we patched into Spark and ran it. Negotiation happened faster and the files transfered. We are having a problem where “retransfers” of files are failing. That is (not in Spark but using the Smack API) files go from:
A->B->C
We get an “unresponsive” error in C complaining about B. We’re not sure yet why this is happening. We have discovered stuff though that makes us feel uncomfortable. For example:
future = service.poll(10, TimeUnit.SECONDS); -----line 96 of FaultTolerantNegotiator.java
SmackConfiguration.getPacketReplyTimeout() * 2); — line176 of FaultTolerantNegotiator.java
inputStream = streamNegotiatorTask.get(15, TimeUnit.SECONDS);— line 193 of IncomingFileTransfer.java
These contain magic numbers (the second to me is th oddest) where things may not be clearing in a manner that arbitrary limits don’t cover. We’ll continue to research.