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

Everything that possibly could go wrong went wrong. Did I drop the ball, did I slack off? Let’s start at the very beginning. About three years ago or so I went to OOPSLA , I’m confused as to whether it was in Tampa or Minneapolis. All I remember, is that STIC had a fairly decent size booth with a gigantic overhead sign and right across from the Microsoft booth. There I setup a camp in one corner and demoed something I called OpentalkMatrix. OpentalkMatrix is something akin to LimeWire or Kazaa but yet different. Like LimeWire and Kazaa it allows users to discover components on a p2p network but it has extended support for VisualWorks code parcels. Anyhow, let’s leave the details for later just suffice to say that the demo worked. I would later go on to demo OpentalkMatrix at NYC Smalltalk and yet again it worked. At home I have a 4 node network including a node on a wireless leg and it works here fine. Prior to the conference , I even tried this out on the network at the office and that worked too. Finally, a couple days before my slot at Smalltalk Solutions I met with one of the principal Cincom Smalltalk engineers in charge of Opentalk development and our dry run went well as well. Of course, the logistics at the demo were slightly different. I did not count with the original presenter running over into my time slot I did not count on my notebook not being able to connect properly to the projector i.e. something that I have done many, many times at NYC Smalltalk, I did not count on a second wireless network in the area. Did not count on having to use TightVNC in quite the way I did. I knew that a live demo was a daring undertaking but I thought I had taken enough spins around the block. Overall, I am pissed and mostly because I do now think that I did slack off. I did not deliver. I did not take the time to control my environment. Anyhow, the only way I will be able to redeem myself is to demo OpentalkMatrix at a global scale i.e. let the Internet be my stage but before I can do that for one we will have to fix one minor issue with Opentalk. More on that later .