- I modified NXB to wait for the <stream:features> stanza to be returned before allowing NXB to respond to the client.
- Pidgin complained about the next stanza it sent after that.
- I tried to modify NXB to wait for the server reply to the <auth> stanza before responding to the client.
- That failed to work.
At this point I am thinking about going with a simpler approach that would use the existing ejabberd BOSH server instead of using NXB. The idea here is that
- An external program would be created to handle HTTP/TCP connections
- The program would enclose the data from the HTTP request in an envelope that indicated a connection number.
- When ejabberd wanted to respond to a client request it would include the connection number.
- The external program would have to read the entire HTTP POST before it tried to send anything to ejabberd.
- Each request would be written in its entirety
- Each request would be from different servers
- The external program would have to "demultiplex" responses to the appropriate HTTP request.
- The ejabberd/BOSH module would be modified so that
- It would start up connections from the external program instead of HTTP.
- It would use the connection ID passed to it by the external program instead of a socket number.
- It would use a new module to respond to requests instead of going directly to gen_tcp.
The external program would need to be very efficient in terms of handling TCP and HTTP connections. nodejs already uses libevent, which consumes only about 2-3kB per connection, so that is a viable choice. I'm thinking the packets sent back and forth would have the following format:
<connection ID>|<length in bytes>|<content>
Where <connection ID> is a 20 digit, 0 padded integer, <length in bytes> is the number of bytes in the <content> section and <content> itself is the message. Both the external program and the ejabberd module would use this format.
The connection ID would simply be incremented with every POST message received.
The nice thing about this approach is that it is relatively simple: the external program does not have to know squat about BOSH and XMPP - it just forwards POST bodies onto ejabberd. For its part, the ejabberd module has to know the connection number that it is responding to, but it currently has to know which port it is responding to, so that should not complicate things greatly.
Of course, it's one thing to look good in theory and quite another to actually be good in practice. Let's see how it works out.
<connection ID>|<length in bytes>|<content>
Where <connection ID> is a 20 digit, 0 padded integer, <length in bytes> is the number of bytes in the <content> section and <content> itself is the message. Both the external program and the ejabberd module would use this format.
The connection ID would simply be incremented with every POST message received.
The nice thing about this approach is that it is relatively simple: the external program does not have to know squat about BOSH and XMPP - it just forwards POST bodies onto ejabberd. For its part, the ejabberd module has to know the connection number that it is responding to, but it currently has to know which port it is responding to, so that should not complicate things greatly.
Of course, it's one thing to look good in theory and quite another to actually be good in practice. Let's see how it works out.
No comments:
Post a Comment