The shoutbox and its usage

The shoutbox should be a lot better behaved now, as I’ve spent quite a bit of time writing some code that handles user registration and authentication. Originally the shoutbox was using anonymous connections which was problematic.

The shoutbox is essentially an Instant Messenger based Group chat - very much like what we’ve got with the Skype group.

This means I can create more rooms if necessary, and you can have private conversations with people. Anyone who creates an account on the site and logs in will have access, although we can kick and ban people out of the chat if we have to.

Probably the best way to use the site while having the shoutbox open, is to open any interesting topics in a new tab or window - this way you won’t have to leave and rejoin the shoutbox again. The shoutbox will not open on topic pages, as multiple connections don’t work too well.

1 Like

Sounds great - well done on haxxoring it to work! :smile:

Just me or not working at the moment ?

TG is still busy :stuck_out_tongue:

Sorry about that, it worked perfectly for about 5 minutes and then the openfire backend decided to just stop responding properly. Had to rebuild it from scratch (fortunately not a complicated process).

Should be working now. :helicopter:

Nope, I have a grey square.

P.S. is it just me or was the site down from yesterday afternoon?

You might be blocked by firewall. I’ve changed the connection settings to try find where the constant disconnection comes in. I’m still working on a solution.

And no, it wasn’t just you, the site is actually running on a brand new server today.

Looking good now, thanks

If you just get a grey box and no shoutbox, it’s because you’re behind a firewall that is blocking the port (7070).
Unfortunately I have not had much luck with reverse proxying the XMPP connection - for some reason nginx just disconnects the session after a minute or so, no matter what I’ve tried - apache handles it just fine, oddly enough. Unfortunately the benefits of using nginx outweighs the necessity of accessing the shoutbox from behind a firewall.
Maybe one day there will be a better solution for the shoutbox, but what I’ve got now will do for the time being.

1 Like

Thx TG. I was wondering why my work laptop didn’t show the shoutbox. Opened that port and now it works fine.

This actually in reply to TG not Gus :blush:

Me shoutbox is broken , now … err: response from server was wrong ?

Yip, same for me

Pfft. You guys don’t read the shoutbox. Otherwise you would know that I was busy changing over to a different binding system so that it will hopefully work behind firewalls and be less flaky.

I’ve come up with some issues, so it is disabled for now, while I try resolve them.

1 Like

So the problem is that punjab is not correctly routing the http bind requests to the xmpp server. For some reason it thinks the xmpp server is on port 80. Fail.

So, an alternative is to patch the BOSH protocol code to generate a route attribute in the authentication XML… that’s a bit beyond me right now. Another alternative is to publish an SRV dns record which punjab should read and then forward correctly. Now of course, I don’t want to take the easy way out and just stick a SRV record on my dns host. Nooo… I figure, let’s modify the dns via a cacheing proxy on the host using dnsmasq, and I’ll have the SRV record there. After messing about and wondering why it won’t work, I realize I have the incorrect syntax for the SRV record in the dnsmasq config. So I fix that, an lo it returns the SRV record. Sweet. I correct the resolver to look at localhost first, and then start up the punjab container. And that proceeds to tell me that I must bugger off with my 127.0.0.1 in my resolver and it’s going to use google public DNS instead. ARGH! I’ve found lots of discussions about this issue, but nothing specific as to WHY the docker creators chose to do this, other than to try ensure that docker is idiot proof, but then it prevents people like me from pulling off some very whacky behaviour, should they require it. Bugger.

Fortunately it’s not the end of the world… my workaround is to use dnsmasq INSIDE the container and tell the container to use 127.0.0.1 as its dns (this would be the container’s 127.0.0.1 and not the host’s). Now I have to fix my build scripts and push them up to github to get the docker index to make a new build. Oh - and what’s annoying is that a script that builds perfectly on my side barfs on the docker index side. I mean, really? It’s supposed to build from the same images. Fortunately it was an easy fix, but still.

(Yes I realize a lot of you are scratching your head at the gibberish I just spouted above, but I have to vent SOMEWHERE, and I don’t know anybody specifically who will understand wtf I’m on about.)

1 Like

TG’s busy breeding some bacon. :slight_smile:

I’m sure he’ll figure it out soon once he is relaxed and bringing home the bacon.

Bacon.

TG, I recognize most of the individual words you are using, but trying to read what you wrote just make my head hurts. Looks like nasty issues. I hope you get it sorted out soon.

1 Like

This forced me to make a better punjab docker container. At least now it can be configured without rebuilding the entire thing. So it’s much more generic, and configurable. Yay!
I’ll look at testing out the punjab container tomorrow. Hopefully I’ll be able to get the shoutbox working with it without too much more pain. At least I’m learning a lot from it.

I’ve spent all this effort with getting a punjab container up and running, but I can’t get it to work.
Oh well, hopefully it will help someone else so it’s not entirely in vain.

I guess it’s time to try a different backend xmpp service.