- Apache proxy
- Encryption
- Protocol clean-up
Apache Proxy
For some reason, when I set up a proxy via apache with NXB, it does not work. I have tried this with JWChat and with Pidgin. When I use those programs, they are able to log on OK and I can send messages. When I try to go through the proxy, it doesn't.
When using JWChat, I get back an error dialog immediately saying the service is unavailable. When using Pidgin, I get a message in the "buddy list" that says it's connecting, but it never changes to connected.
 |
| Connecting but never connected |
When I try using these programs directly to the NXB port, everything works. It only seems to happen when I go through the proxy.
Encryption
This is a potential problem where using encryption could cause problems between NXB and ejabberd.
megaphone deals only in complete stanzas. If everything is encrypted, including the stanza tags, then it becomes impossible to tell where a stanza starts or ends. Therefore, megaphone could end up sending partial stanzas to ejabberd, which could cause problems if ejabberd is not buffering things.
These are potential problems: it may well be that ejabberd can handle packets of scrambled data just fine, thank you; but I'm a worrier so here it is.
Protocol Clean-Up
The megaphone protocol does not address issues like error handling or signaling. For example, if ejabberd or NXB has a problem with a connection and wants to close it, it can send a close request, but there is nothing stopping the other side from continuing to use that connection. To make matters worse, there are no acknowledgments in the current version of the megaphone protocol.
At some point, clean up the protocol and update the plugins on the NXB and ejabber sides to use it.
Possible Memory Leak
If a client asks for data for a connection that the system has not received any packets for, the system will create a new entry in the waiters table for it. If data never arrives for that connection, the entry just stays in the table. If this often happens, then the table will grow without bounds, increasing in size until it crashes the system.
Blocking Status Check
The status check in megaphone should probably not synchronously call the status check in megaphone_sender, or at the very least it should use a timeout. The status check has the potential to cause the megaphone sub-system to block indefinitely waiting for a reply.
Protocol Clean-Up
The megaphone protocol does not address issues like error handling or signaling. For example, if ejabberd or NXB has a problem with a connection and wants to close it, it can send a close request, but there is nothing stopping the other side from continuing to use that connection. To make matters worse, there are no acknowledgments in the current version of the megaphone protocol.
At some point, clean up the protocol and update the plugins on the NXB and ejabber sides to use it.
Possible Memory Leak
If a client asks for data for a connection that the system has not received any packets for, the system will create a new entry in the waiters table for it. If data never arrives for that connection, the entry just stays in the table. If this often happens, then the table will grow without bounds, increasing in size until it crashes the system.
Blocking Status Check
The status check in megaphone should probably not synchronously call the status check in megaphone_sender, or at the very least it should use a timeout. The status check has the potential to cause the megaphone sub-system to block indefinitely waiting for a reply.
