Forum OpenACS Q&A: Is someone interested in the ACS 4.x Java Chat Module for openacs 3.2.x?

Hi all!
I just backported the ACS 4.x java chat module to openacs 3.2.5, it works with the openacs 3.2.x chat module datamodel, its pretty nice (comparing it to the slowly chat version). If someone is interested I can do a release of the module and document the installation process (that its pretty easy, once you know how to do it).

So, for instance you can give in you site a chat with a HTML, Javascript and Java interfase. Sounds good don't you think!

Please tell me what do you think! =)

Check it out here!.
Login as: anonymous / changeme

I would like to port it to OpenACS 4.x, please tell me with who I need to talk in order the get that module assigned to me.
You need to talk to me, but obviously it won't make it in with this first release.  Which is no big deal, when we get our repository up we can just stick it in there.

It doesn't look like the package would be all that hard to port to OpenACS 4/PG ...

Did aD provide a Javascript client or just the Java interface for the 4.x version?

Anyway ... what do folks think?  I know some folks are more interested in interfacing to Jabber and possibly IRC but having a standalone chatter package doesn't mean we can't latter support other options.

Rocael - I think the design of the existing ACS 4 chat package would eventually become obsolete.  Even in the short term the transcript logger probably wants to hook up to the RSS package to allow offsite  logging of the transcript.  In the longer term it may need to support various protocols as mentioned above which would probably mean modularizing it to a fairly high degree.

I think, anyway, I haven't thought much about it (maybe others have?)

But maybe having a port of the existing chat (interfaced with the RSS package?) would start the ball rolling towards a more interesting future version.

Well, I'm really interested in the Jabber module, but in my case I needed it quickly so I did it. I guess is ok the Java version, wich also have a HTML interfase. Anyway I personally think that the module is good, that the porting won't be so hard and you probably always will want to have a chat module (that also has an instant messanging options, P2P messages between participants in a room) for casual users that doesn't want a more sophisticated messanging system like jabber.

So if there are a really community interest I offer myself to port it.

By the way, I do really need the jabber interfase, probably in a couple of weeks I'll start looking to add it to openacs 4.x, we need it for a future site that needs to be available in around 6 to 8 weeks!
I think that there should always be a package available that doesn't require any special client installs or dependency on java or javascript working on the client side etc.  I participate with an international group that wants both "modern" conveniences and a backup in case the fancy one doesn't work. Sometimes one only has options to chat via half-broken clients or unpopularly configured machines etc.

So, I suggest keeping the original http ACS chat, and adding at least one of the others...

Well Torben, actually the openacs 3.2.x has a html and javascript version that really doesn't scale, I would say that really doesn't work for real use so that is why I backported. And the actual openacs 4.5 won't have a chat module, if so, it could start with the original java chat 4.x that has a java interfase as well as a HTML one.
Rocael, it seems like your Java/Html version is consistent with the needs of users that I'd like to see using OpenACS some day soon... Great!
E-mail me in private, Rocael, if you want to take this first step on, and we'll chat about CVS access, things you need to do to support both RDBMSs, etc.
Rocael, that is very cool!  Thanks for sharing.  I haven't used too many chat environments, but it seems to be quite an improvement over the previous ACS 3.x built-in version.

I have had some pressure to produce a near-term chat solution on OpenACS 3.2.5, so this looks pretty good to me.  I would definitely be interested in the backported module and your documentation of the installation process.

BTW, were we at the ACS 4 boot camp together last year in Pasadena?

Hi Walter!

nice to hear from you again... I can't believe that a year later after the bootcamp aD doesn't exists anymore... that's sad =(

well, I'll work on the backport docs and distribution and as soon as I can I'll share it here and to you. Then I'll start in porting it to openacs 4.x, I also need it at ACES 3.4.... chat,chat,chat....

bye, =)

Hey Rocael!  Yeah, it's too bad about aD, but it's great that we're able to keep the original spirit alive here and do so many cool things on top of their code base.  So many companies have gone down without a trace.

Meanwhile, it looks like you're keeping really busy with OpenACS projects.  Refresh my you run your own consulting business?

Looking forward to checking out your chat backport....

You are right Walter, its nice to keep the spirit alive!

Well, I'm really busy with my consulting company, because my work consist in create online strategies that works for differente kind of business, so I see marketing, promotion, community, organizational and technology stuff for guiding a company to have a successful online community and/or knowledge system.

chat,chat,chat, yes =) soon =)

Rocael. It seems you just made my day with this chat. One question form a user perspecive remains. How hard is it to ad a sound to it so when visitors enter the chat room, a moderator hears a bell or something. This solves the dissapointing situation people have when they visit a chat and there is noone to talk to. I am currently bypassing this ommission by refering to liveperson through a hyperlink on my chat room. Here is there source code ....

I look forwared to be able to replace our current ACS chat with your alternative.

I think it is not too difficult the sound thing, but right now I don't know exactly how to do that, maybe in the near future I can add that funcionality because its really a good point, because you don't need to be waiting with the window in from of your screen in order to know if someone has entered in the chat.

Well, I'll release soon the jchat for openacs 3.2.x and then to openacs 4.x.


Malte just released a jabber module for AOLserver... It might help you with your Jabber task:

I am looking forward testing your ACS Chat backport...

David, I've already exchanged some emails with Malte, so from that point i'll start.

Jchat for 3.2.x will come soon!

Another little thing...

I find moderated java based chats pretty useful for discussions involving one "expert" who gives answers and many people that post questions... The thing about those moderated chats is that a moderator intercepts all the questions and posts only those to the public that are being answered... This way you could cut off unwanted commercial posts in big public discussions. Also if too many people posted questions at the same time the answers of the expert would get out of sight pretty quickly!

Have you done anything in this field?

Well David, this features of moderated chats the module already has (in openacs 3.2.x it still has some bugs that i've already fixed), the original and the jchat, but I still have some trouble with it in the backport, I mean, it works fine but I wanted to be able to moderate a chat room in java and HTML versions, if I can't go through this I'll enable just to be able to moderate a chat room in java version. But yes, the chat has a moderated feature.
18: another optional feature? (response to 1)
Posted by Ben Koot on
My colleague Hans Gaasenbeek pointed me towards Babylon Isn't this something you have been looking for David. I mean the drawing function. Maybe someting like this could also be included in future chat solutions, as option or something. I mean, that give htm, javascript, jabber, interactive drawing, ... just a thought.
Wow, my little P200 firewall/IP Masq'er went down last night and I didn't figure out that it was it and not my DSL line until about 30 minutes ago, and look what's happened?

Tons of chat about chat!  Cool.  Good news on Malte's Jabber module for AOLserver.

Rocael's e-mailed me about doing the OpenACS 4.5 post-release port and I'm excited, this sounds pretty cool.

Rocael - you might want to start a thread over in the 4.x design forum about the basic structuring of the presentation (chat admin pages/Java client, etc) vs. those pieces doing the actual protocol stuff.  You're probably going to want to do some redesign of the package as it stands now and I'm sure folks will be eager to discuss it.

Does this sound like a good idea?

I'll do it Don, but first I would like to release the backport for 3.2.x
Yeah, you should do that, I'm not trying to discourage you from getting your 3.2 stuff out to folks!
22: testing (response to 1)
Posted by Ben Koot on

It maybe usefull to know I have a professional testing team of 8 corporate secretaries available on-line every working day. So if you would like to get some feedback from chatters, that have been using the current ACS chat, aswell as, let me know what we can do to help you with the usability testing. I can assure you they realy can be fussy 😉)) . By the way the same counts for any other modules. Theare are curently using the Intranet, which I am currently using to give them on-line offices and homepages.

I would love to see this chat module integrated into OpenACS 4.
I'm planning on installing the beta as soon as I get more
memory for our Linux box, and this functionality would be a
welcome addition.
Thanks Ben for your offer, I'll write you when I have something where they can try, that'll be nice ;)

Julie, soon you'll see that.

25: Jabber Integration (response to 1)
Posted by Malte Sussdorff on
Before this gets lost: We will explore ways to integrate the Jabber Module for AOLserver into ACS and OpenACS. Once our developers are back from skiing in the alps we will start a thread in the OpenACS Design BBoard discussing ways for integration and implement them in both OpenACS 4.5 and ACS 3.5. One objective will be to have groupchats which originated within a community (aka group, aka class) searchable accessible and searchable for members of this group (at least).

After reading the Jabber mailing lists for six months or more, I finally got an idea on what kind of software should be built into AOLserver to interface with a Jabber server. Instead of writing a client, as I did, and I guess Malte and his students have done, the thing that is needed is a Component. The most relevent link is, but generally a component uses a slightly different protocol than the client protocol, but once authenticated to the server, it acts as a part of the server. My suggestion is to write an AOLserver C module very similar to my current module, but connecting as a component. My Jabber module is relatively simple: it simply passes a reference to each packet into the tcl api. It also wraps the most useful packet handling api functions in libjabber. The main downside of my module is that libjabber seems to be an abandoned library. I think there might be a more useful library somewhere, but I have not been able to find it. I did replace some of the libjabber implimentations to better support detecting server/client disconnect. Currently the software required to use this module are at I wish I had installed Malte's module for comparison, has anyone else compared the two?

I'm planning to integrate the java 4.x chat to the ACES 2.0 in order to have the funcionality for groups, classes, communities... but anyway we are interested in integrate jabber to the ACES.

I though that the jabber module that Malte used was from Tom, so I'm wrong... probably the first step as far as I understand is to see the component for aolserver, and then integrate it to openacs 4.x or acs 3.5

Lets start a thread about the jabber-aolserver-openacs design interfase.

I spent some time today looking at the jabberd library. It has some of the same stuff as libjabber does, what is missing is the jconn structure which maitains info about a jabber connection. Hmm, how do they do this in jabberd. Probably I would need to re-write the connection parts of the client/component.

The benefit of writing a module that can act as a component is that then AOLserver/OACS becomes a jabber component which can offer services to any jabber server. These services can be anything, and might be easier to do in our favorite software than in perl/java/...

Tom, your thoughts are very interesting because it brings up a point that the Jabber community is beginning to move to as well. That is using Jabber not just as an IM system but as an XML "middlware" application as well.

For instance, using Jabber to post content, as an XML-RPC conduit and as an "alarm" system. Alot of this studd is experimental even in the Jabber community, but is this some of the stuff you were talking about that Jabber integration could provide in OACS?


As a client, I think you can hack your way to a workable solution for some of these things, but as a component OACS/AOLserver would be part of the Jabber server, or maybe would use the Jabber server as it's dog for all the routing stuff. As a component, the Jabber server would see the OACS as: a user database, a content library, an email conduit, a blog, only depending on the programming done in OACS/AOLserver. The truth is the Jabber community is very good with the plumbing, and IM, but not too tuned in to the http type applications most of us are used to: bigger, fatter and not necessarily human attended. The one painful application I saw, which introduced me to Jabber in August, I think it was a survey bot, could probably be done with simple survey with a little hacking. The example I saw was never finished, so difficult to use is the perl library for anything beyond chat.

One thing to note also, is my module gives a great example of using one client connection that de-multiplexes into OACS with the dqd threadpool module so that database activity doesn't slow things down. So you end up with one thread in, many execution threads, and one thread back out. Another interesting feature I discovered is the ability to inject (like internal redirect) packets into the stream, to skip from one 'url' to another. I also experimented using the thread tag as a url. All of this would have been painful, I believe, except for the fact of AOLserver/Tcl. Anyway, having two OACS/AOLserver setups would allow using some kind of specialized namespaces to transfer data. One thing to note is that jabber packet size maxes out at at most 500k, but again a namespace might be developed to allow message disassembly/reassembly.

Tom, how hard would it be to tie the Jabber component into
acs-messaging (or is it acs-mail)? The most obvious and
immediate application for Jabber-in-OpenACS beyond IM and
chat is to use the Jabber conduits to route email alerts to
alternate delivery vehicles (IM, SMS, etc.). I'm imagining a simple
UI for end users that allows them to enter their various alert
"targets" (including alternate email addresses) and allows them
to designate which of those targets should receive particular

This could be scoped per instance per package, so that, for
example, I can get pager alerts from my tech support bboard but
not from my app design bboard. Certain apps might conceivably
even want finer scoping than this. For example, I might want
ticket-tracker to give me pager alerts for new bugs assigned to
me but not for messages letting me know that particular bugs
have been closed.

On the other hand, the list of conduits available to the user (from
which these preference dialogs would be drawn) should be
scoped to the user, i.e., I shouldn't have to re-enter my email
addresses, pager numbers, etc., for every scoped application.

Okay, the software I wrote is a jabber client. A tiny rewrite or addition to the C code would allow connection as a component. You would not necessarily need to do this for your intended purpose: sending messages. Just like bboard alerts, messages can be from a single account ( However, my module also connects to any jabber server as any user, assuming you have the password, so each module could setup it's own connection and send messages as it wishes. All you need to do is to write the code that figures out the jabber user address 'user@domain/resource', build the xml (easy) and send. The jabber coding only takes a few minutes.

Thanks Rocael!  I can't wait to try installing it (I guess I'll finally get around to putting Java on my server).  That's pretty cool that the Java and HTML versions can interact, although as you said, for most people the HTML version will probably be a last resort.
Hello Rocael,

I just installed your java chat and it works great...

Just a minor thing:

1. You have something hardcoded in the proc chat_start_server

java -classpath /web/jchat/www/chat/java adChatServer start $port &

should be

java -classpath /web/yourserver/www/chat/java adChatServer start $port &

2. I installed j2sdk1.4.0 instead of jdk1.3.1_02 (showld be okay shouldn't it?)


I am pretty new to java and I tried to change some little things in the applet like translating the buttons "Ignore" "PM" etc. to their German equivalent, but it didn't really work...

1. Stopped the chat server with "java -classpath MyClassPath adChatServer stop MyPort"

2. I deleted all *.class from chat/java

3. Changed the appropriate .java files

4. Compiled all .java files with "javac *.java" (Get a little error message, which is not too important (isn't it?): warning: getFontMetrics(java.awt.Font) in java.awt.Toolkit has been deprecated
fm_normal = toolkit.getFontMetrics(font_normal);

5. Restarted the chat server with "java -classpath MyClassPath adChatServer start MyPort"

But NOTHING changes....

Is good David to know that it worked, well I wanted to name it as beta because I've released it quickly without checking everything carefully.

JDK 1.4 is ok, what linux are you using?

About the java stuff, its pretty easy (although I don't know really what that minor warning...)

When you have changed the appropiate *.java files, run javac *.java if you want, but what you really need to do is generate a complete applet .jar, that's the file that jchat.tcl calls.

So run this simple command in /web/yourservice/www/chat

jar cvf chat.jar chat/

This should work.

Hey Rocael.

I just finished installing it, and it's working great. Yeah!!

I had the same issue as David, along with one minor twist. For some reason I had to specify the full path to java for it to start the chat server (from the chat_start_server proc in the jchat-procs.tcl file):

exec /usr/java/jdk1.3.1_02/bin/java -classpath /web/[my server]/www/chat/java adChatServer start $port &

Otherwise, I would get the following error in the log:

Error: couldn't execute "java": no such file or directory
couldn't execute "java": no such file or directory
    while executing
"exec java -classpath /web/dev-ktyf/www/chat/java adChatServer start $port &"
    (procedure "chat_start_server" line 14)

I verified my nsadmin (and root) environment variables, and I was even able to run it from the command line, so I don't know why it couldn't find it. But once I added the path it worked fine.

David, you can safely ignore the warning from the java compiler. It's just telling you that you're using a method that is deprecated, but it is still supported (just that it might not be supported in future releases). Or you can try replacing it with the new method suggested by the compiler if you don't want to get that message.


I also had to define the full path for the exec command although I am able to start java or javac from the command line (nsadmin and root)...

I get this message:

[15/Mar/2002:16:49:04][4489.5126][-conn1-] Notice: Starting chat server
Exception in thread "main" java.lang.NumberFormatException:
    at java.lang.Integer.parseInt(
    at java.lang.Integer.parseInt(
    at adChatServer.main(

What could be wrong?

Hmm... Seems like I forgot to add the parameters to /web/[myserver]/parameters/[myserver].tcl. Done. Still... the same error.

Things are more difficult as I am using Jerry Asher's nsunix modules... This will forward to unix://myserver.nsunix


ns_section  ns/server/master/module/nsvhr/maps
ns_param    unix://myserver.nsunix
ns_param    unix://myserver.nsunix

I have not specified any ports (and still normal http works):


#set httpport              80

Would it be possible to use the chatserver on port 80 together with http? Or should I make a new nsunix socketfile? Dunno. Well, I'll try things out.

Ah, I got it working. It runs seperately from Aolserver.

Can I run it as root - and how? The point is, my dear colleague Ben wants me to run it on a port like 80 (althought this one is already taken by Aolserver), because some users are behind a firewall and cannot use port 8040. If I want to run it on e.g. port 21 (I have no FTP server running), I guess it must be run as root.

And it is unsafe I guess.

Well Hans, you should be able to run it in a reservated port, as root without problems (I have never thinked about it before), start the aolserver as root running your nsunix and the port for http that you have chosen, maybe its a security risk. I would suggest you to indicate to your users that if they can't use the java chat because the firewalls, they can still try the javascript or html version without problems!

The jchat doesn't care about nsunix or stuff like that, just asign an IP, a port, and thats it!

Hans, you won't be able to run the chat server on the same port as AOLServer, because as you noted it's a separate service that needs to bind to its own port.

As for running it on a privileged port, I don't know if it's unsafe or not. You could start it up separately as root by calling it from a script, like inittab, or even from the command line: java -classpath /web/[my server]/www/chat/java adChatServer start [my port #] &

AOLServer itself doesn't run as root, even when bound to a privileged port, and perhaps the chat server could be started in a similar manner. I don't know how that's accomplished, so maybe someone else can comment on that.

Walter is right!, about security issues ain't shure, but maybe you can run the server as Walter indicated in a chroot jail!, that will give more security ;)
Is anyone else getting stale connections hanging on the chat server port?
tcp        0      0     CLOSE_WAIT
tcp        0      0     CLOSE_WAIT
tcp        0      0     CLOSE_WAIT
tcp        0    153     CLOSE
tcp        0      0     CLOSE_WAIT
tcp        0    153     CLOSE
tcp        0    100     CLOSE
tcp        0    153     CLOSE
tcp        0      0     CLOSE_WAIT
tcp        0      0     CLOSE_WAIT

I seem to get these connections that just hang there in a close or close_wait state indefinitely. I haven't put much traffic on it yet, so I don't know if it's an issue. Just curious if that's expected behavior.

Thanks for the suggestions... I have decided to leave it as it is... you cannot always make everybody happy, and indeed as Rocael suggests the few users who cannot use the JAVA chat can use the javascript version or HTML.

One thing that maybe needs some changing is the private chat. When the entire window is full with messages (like 5 from both users) new messages do not appear - that is, until one posts a couple more messages so that the 'old' ones are pushed up. (I hope this is understandable...) Is there a solution for that?

The way to fix that behavior would be to modify the client applet, I believe.  I'm hoping to do some work on the chat client, although I'm not sure when I will get the chance.  There are a number of enhancements I would like to make, particularly the addition of sound, and the issue with the private messaging would be good to fix as well.

Okay, the software I wrote is a jabber client. A tiny rewrite or addition to the C code would allow connection as a component. You would not necessarily need to do this for your intended purpose: sending messages. Just like bboard alerts, messages can be from a single account ( However, my module also connects to any jabber server as any user, assuming you have the password, so each module could setup it's own connection and send messages as it wishes. All you need to do is to write the code that figures out the jabber user address 'user@domain/resource', build the xml (easy) and send. The jabber coding only takes a few minutes.

Very cool, Tom.

I have couple little problems with the java chat:

1. The regular and the privat chat doesn't automatically scroll down the posts when the number of posts exceeds the height of the window...

2. German characters are displayed correctly in the chat window but displayed as spaces in the input window...

3. Concerning the stale connections:

I don't know if this is a bug or a feature, but on my way to checking it out I encountered:

responding to the issues from your last post....

1) My fix for auto-scrolling to display the latest messages is to add a couple lines to the source files:

a) At the end of the receiveMessage method in the file, add the following (at line 372 in the original source):
    // Auto-scroll to display the latest message
    int height = text_area.getViewportSize().height;
    text_area.setScrollPosition (0,height);
b) At the end of the receiveMessage method in the file, add the same lines (at line 120 in the original source).

c) Recompile (let me know if you need the details).

c) I also had to close existing sessions to get my browser to reload the recompiled applet.

2) I'm not too familiar with character set issues, so maybe someone else can help. However, I know that in Java you have to use the appropriate data types (or Classes) to handle international characters. I'm guessing that it wouldn't be too difficult to make the necessary changes. I'm pretty much of a Java newbie, but let me know if you have trouble figuring it out and I'll try to take a closer look.

3) Are you getting the connections lingering on your chat server port? It would help to know if anyone else is getting these stale connections, so I know whether to look at the OS or the chat server code. Interesting that you should point to that link. I've secured and optimized my machines by following those instructions to the letter (and I've been extremely happy with the resulting configuration). So I've already implemented the recommended network optimizations.

Hello Walter,

I applied your scrolling fix and it works for the first ~30 chat messages, but after that the scroll bar on the right doesn't get smaller but moves to the top and again covers the latest messages...

I checked with netstat -t about stale connections.... I also have some lying around with close_wait, but not as many as you (max.3). Have you been hitting hard on the chat module with couple simultanous users??? Because on my system it's only me at the moment, so this could change when installing the module on my production server!

David, try  text_area.setScrollPosition(0,text_area.getVAdjustable().getMaximum());

It will work...

About CLOSE_WAIT TCP/IP state: it appears when the other endpoint of the socket connection disappear abruply and the TCP/IP stack could not receive any acknowlegdment packet from the other side, so it has to wait to be sure that the other side is surely down. It is possible to modify this TCP timeout.
Well, mine was a Java newbie shot in the dark, so I'm glad you came up with the real answer, Neophytos

Meanwhile, Michael's comment supports my (untested) suspicion that the socket connections aren't getting closed when someone leaves the chat without clicking the "Log Off" button.  I think that will be a relatively frequent occurence, so it would be nice to figure out how to close those connections down properly.  My tests have been pretty limited, with only a couple users in brief chat sessions which generated a number of stale connections, and I wonder what the implications would be for a production environment.

Michael, do you think it's appropriate to handle the stale connections by changing the OS configuration to time them out?  It does seem like it would make sense for them to be dropped eventually, because right now they appear to linger indefinitely or until the chat server is restarted.

At the current moment I am a little confused about my interpretation of CLOSE_WAIT TCP state. Let me read my Richard Stevens source to confirm the exact problem: one side never closing the socket or one side abruptely out of the network.
Back about the CLOSE_WAIT state: according to R Stevens, it is clearly a problem in the server nerver closing the socket. Usually it is because one do not known that when a read return 0 bytes it means that the other side has closed the socket and the server should close it.

Should the server close the connection when the other side is disconnected from the network, you would see FIN_WAIT state in netstat.

conclusion: that seems to be a bug in the server.

Is anyone familiar with tunneling java applets through the http port 80?

I found this webpage, but it doesn't really have any instructions... (

Any pros or cons?

Hans, did you get it running in a chroot environment on port 21???

That HTTP tunnel looks interesting. I wish they had included more information.

For those interested in a sound alert when a message comes in, here is how I did it:

At the end of the receiveMessage method in the file, I added the following:

       // Play a sound effect when the message arrives
       AudioClip audio = getAudioClip(getCodeBase(),"message-notify.wav");;
Hello Walter,

we might take tunneling code that is already written in java and integrate it into the oacs java chat...

check out the class TunnelServlet

"Up to version 1.0.6-rc2, it used to be pretty hard to get this all to build and run, especially the http-tunneling support..." (

That was the only gpl java chat that I found. Maybe somebody knows of others that we could get the tunneling code from ...

Hey David.

That's more interesting stuff....  I'm especially curious about the HTTP tunneling.

The issue of traversing corporate firewalls is unfamiliar to me, so let me see if I have this straight.  As I understand it, the firewall restricts traffic to familiar ports with one or more specific protocols associated with each open port.  So to get stuff in and out of port 80, it needs to be http?  Is this what is meant when people say they can't use java because they're behind a firewall?

The issue that comes to mind is that you can only have one service listening on a given port.  So if you have AOLserver listening on port 80, to my knowledge you can't share that port with a chat server.  Does that mean you would run the chat server on port 80 on another IP address?  Or would the chat server, or some kind of http tunneling middleware, be the service listening on port 80, brokering the requests and routing them to the appropriate web/chat server?

I'm kind of thinking out loud here, trying to understand this stuff, but if you have an answer I'd be interested.

the firewall restricts traffic to familiar ports with one or more specific protocols associated with each open port. So to get stuff in and out of port 80, it needs to be http?


Is this what is meant when people say they can't use java because they're behind a firewall?

YES! sometimes is restricted to privileged ports and sometimes to the ports and specific protocol together.

The issue that comes to mind is that you can only have one service listening on a given port. So if you have AOLserver listening on port 80, to my knowledge you can't share that port with a chat server. Does that mean you would run the chat server on port 80 on another IP address?

I think this is the best solution

Or would the chat server, or some kind of http tunneling middleware, be the service listening on port 80, brokering the requests and routing them to the appropriate web/chat server?

this will be more complicated I guess, it easier to have a specific IP for your chat, more when that is very popular, maybe the chat service is running in a different machine in that case.
fake twats u lot