Opentalk is great, Its a well factored and thus extensible framework. It allows local and remote objects to interact transparently. However, it has a couple major flaws at least in the context of p2p. In my previous post I mentioned that I had coded my Kazaa like prototype about 3 years ago. Well, I did not do much after that and the reason was that I encountered a problem that bummed me out. I discovered that I was not able to get past NATs. To be more accurate the problem is with Opentalk ST-ST i.e. the Smalltalk to Smalltalk distributed messaging mechanism. I plan to document this in detail later but for now the issue is that an OT message is tagged with the ip address of the OT broker sending the message and that is the ip address that is used to respond to the message. So if your broker is behind a NAT on 192.168,20,3 when the guy on the other end receives the message it will try to use that ip , well get the picture, not pretty. We really need the notion of our “public” ip or better still the notion of an access point needs to be made more robust. So what’s the impact of this on OpentalkMatrix? If you are directly connected to the Internet and so are your peers then there is no problem. So there is a problem since many will be behind home routers and therefore NATs. This however does not mean that Opentalk ST-ST is useless. It means that one can use Opentalk ST-ST for most corporate type of deployments where the nodes are within a corporate network or VPN but again currently hostile to p2p deployments.

Anyhow, this has to be fixed. The Opentalk team had been stuck doing unimportant stuff like Web Services, a ton of crypto, SNMP to name a few but enough is enough. The fix should not be that hard and its something that is best that they do. So if you think that this is important i.e. OT surviving past a NAT then please let the product manager for Cincom Smalltalk know. Hint his first name is James and he is a very active blogger