Smalltalk › Cincom › VisualWorks

[vwnc] Opentalk STS across two machines

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Gregory Bourassa-3

[vwnc] Opentalk STS across two machines

Using Opentalk, we are trying to set up communication between two
running images on different machines.

The examples in the OpentalkDevGuide book all assume brokers in the same
image on the local machine...and they run fine that way, generally.
We have managed to communicate between two different images on the
_same_ machine; but for the same example(s) on two machines, no joy.

One smoking gun is in the STSTRequest>>evaluateFor: method, where it
calls self validate...so STSTRequest>>validate. This method always
throws the exception captioned 'The message receiver is not on the server'.

All we did was modify the examples from the document to run across two
machines instead of one. For example on host tweedledee we evaluate
this in a workspace:

server := RequestBroker newStstTcpAtPort: 4242.
server start.

Then on host tweedledum we evaluate this:

client := RequestBroker newStstTcpAtPort: 4243.
client start.
remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
remote echo: 'Hello'

This just never works, for the reasons mentioned above -- the exception
purposely raised for the target being remote.

What are we leaving our or doing wrong. It just doesn't seem as though
it should be so hard to modify the examples for multiple machines!

Thanks for any help.

Gregory Bourassa

-----------------------------------------
DISCLAIMER: This email is bound by the terms and conditions
described at
http://www.key.net/disclaimer.htm
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vwnc] Opentalk STS across two machines

Hi Gregory,

I have just tried the example code on two machines and it just works for
me. What version of VW are you using and are there any firewalls in between?

Regards,

Cham

Gregory Bourassa wrote:

> Using Opentalk, we are trying to set up communication between two
> running images on different machines.
>
> The examples in the OpentalkDevGuide book all assume brokers in the same
> image on the local machine...and they run fine that way, generally.
> We have managed to communicate between two different images on the
> _same_ machine; but for the same example(s) on two machines, no joy.
>
> One smoking gun is in the STSTRequest>>evaluateFor: method, where it
> calls self validate...so STSTRequest>>validate. This method always
> throws the exception captioned 'The message receiver is not on the server'.
>
> All we did was modify the examples from the document to run across two
> machines instead of one. For example on host tweedledee we evaluate
> this in a workspace:
>
> server := RequestBroker newStstTcpAtPort: 4242.
> server start.
>
> Then on host tweedledum we evaluate this:
>
> client := RequestBroker newStstTcpAtPort: 4243.
> client start.
> remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
> remote echo: 'Hello'
>
> This just never works, for the reasons mentioned above -- the exception
> purposely raised for the target being remote.
>
> What are we leaving our or doing wrong. It just doesn't seem as though
> it should be so hard to modify the examples for multiple machines!
>
> Thanks for any help.
>
> Gregory Bourassa
>
>
>
> -----------------------------------------
> DISCLAIMER: This email is bound by the terms and conditions
> described at
> http://www.key.net/disclaimer.htm
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

kobetic

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

As Cham already reported, there's nothing clearly wrong with your example code. However if you're getting the OtEInvalidObjectReference exception refusing to accept an incoming request, it might be that the server broker thinks it is running at a different IP address/port than the incoming request indicates. Put a breakpoint into the #validate method, and compare the address/port in the 'target' to the 'broker accessPoint'.

The issue is that the broker needs to figure out the IP address of the machine it is running on. Currently we're using reverse DNS for that, i.e. we ask the host for its hostname and then do a reverse lookup with that name. This usually works, but can fail in interesting ways depending on specifics of your network configuration. Take a look at GenericProtocol>>setHost to see what's going on in your case.

HTH,

Martin

"Gregory Bourassa"<[hidden email]> wrote:

> Date: December 3, 2008 20:17:26.000
> From: "Gregory Bourassa"<[hidden email]>
> To: [hidden email]
> Subject: [vwnc] Opentalk STS across two machines
>
> Using Opentalk, we are trying to set up communication between two
> running images on different machines.
>
> The examples in the OpentalkDevGuide book all assume brokers in the same
> image on the local machine...and they run fine that way, generally.
> We have managed to communicate between two different images on the
> _same_ machine; but for the same example(s) on two machines, no joy.
>
> One smoking gun is in the STSTRequest>>evaluateFor: method, where it
> calls self validate...so STSTRequest>>validate. This method always
> throws the exception captioned 'The message receiver is not on the server'.
>
> All we did was modify the examples from the document to run across two
> machines instead of one. For example on host tweedledee we evaluate
> this in a workspace:
>
> server := RequestBroker newStstTcpAtPort: 4242.
> server start.
>
> Then on host tweedledum we evaluate this:
>
> client := RequestBroker newStstTcpAtPort: 4243.
> client start.
> remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
> remote echo: 'Hello'
>
> This just never works, for the reasons mentioned above -- the exception
> purposely raised for the target being remote.
>
> What are we leaving our or doing wrong. It just doesn't seem as though
> it should be so hard to modify the examples for multiple machines!
>
> Thanks for any help.
>
> Gregory Bourassa
>
>
>
> -----------------------------------------
> DISCLAIMER: This email is bound by the terms and conditions
> described at
> http://www.key.net/disclaimer.htm
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

kobetic

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

I should add that the 'target' should not be 'remote' by the time the request gets to the #validate method. It should be resolved to a local object during un-marshaling. If it is remote it might be helpful to hook into the localityTest and see why it decides that the target isn't local. One case when you may need to customize the locality test is when you have a host with multiple network interfaces. By default the broker assumes there's only one, so on a multi-homed system it will latch onto the one returned by the DNS lookup. And if there's connection coming through any of the other interfaces, the default locality test is likely to fail those.

HTH,

Martin

[hidden email] wrote:

> The issue is that the broker needs to figure out the IP address of the machine it is running on. Currently we're using reverse DNS for that, i.e. we ask the host for its hostname and then do a reverse lookup with that name. This usually works, but can fail in interesting ways depending on specifics of your network configuration. Take a look at GenericProtocol>>setHost to see what's going on in your case.
>
> HTH,
>
> Martin
>
> "Gregory Bourassa"<[hidden email]> wrote:
> > Date: December 3, 2008 20:17:26.000
> > From: "Gregory Bourassa"<[hidden email]>
> > To: [hidden email]
> > Subject: [vwnc] Opentalk STS across two machines
> >
> > Using Opentalk, we are trying to set up communication between two
> > running images on different machines.
> >
> > The examples in the OpentalkDevGuide book all assume brokers in the same
> > image on the local machine...and they run fine that way, generally.
> > We have managed to communicate between two different images on the
> > _same_ machine; but for the same example(s) on two machines, no joy.
> >
> > One smoking gun is in the STSTRequest>>evaluateFor: method, where it
> > calls self validate...so STSTRequest>>validate. This method always
> > throws the exception captioned 'The message receiver is not on the server'.
> >
> > All we did was modify the examples from the document to run across two
> > machines instead of one. For example on host tweedledee we evaluate
> > this in a workspace:
> >
> > server := RequestBroker newStstTcpAtPort: 4242.
> > server start.
> >
> > Then on host tweedledum we evaluate this:
> >
> > client := RequestBroker newStstTcpAtPort: 4243.
> > client start.
> > remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
> > remote echo: 'Hello'
> >
> > This just never works, for the reasons mentioned above -- the exception
> > purposely raised for the target being remote.
> >
> > What are we leaving our or doing wrong. It just doesn't seem as though
> > it should be so hard to modify the examples for multiple machines!
> >
> > Thanks for any help.
> >
> > Gregory Bourassa
> >
> >
> >
> > -----------------------------------------
> > DISCLAIMER: This email is bound by the terms and conditions
> > described at
> > http://www.key.net/disclaimer.htm
> > _______________________________________________
> > vwnc mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mark Plas

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Hi Gregory,

We ran into something like this just a few weeks ago and the reason was a firewall running on one of the computers.

Perhaps this is the reason for your problem?

Mark

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Gregory Bourassa
Sent: donderdag 4 december 2008 2:17
To: [hidden email]
Subject: [vwnc] Opentalk STS across two machines

Using Opentalk, we are trying to set up communication between two
running images on different machines.

The examples in the OpentalkDevGuide book all assume brokers in the same
image on the local machine...and they run fine that way, generally.
We have managed to communicate between two different images on the
_same_ machine; but for the same example(s) on two machines, no joy.

One smoking gun is in the STSTRequest>>evaluateFor: method, where it
calls self validate...so STSTRequest>>validate. This method always
throws the exception captioned 'The message receiver is not on the server'.

All we did was modify the examples from the document to run across two
machines instead of one. For example on host tweedledee we evaluate
this in a workspace:

server := RequestBroker newStstTcpAtPort: 4242.
server start.

Then on host tweedledum we evaluate this:

client := RequestBroker newStstTcpAtPort: 4243.
client start.
remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
remote echo: 'Hello'

This just never works, for the reasons mentioned above -- the exception
purposely raised for the target being remote.

What are we leaving our or doing wrong. It just doesn't seem as though
it should be so hard to modify the examples for multiple machines!

Thanks for any help.

Gregory Bourassa

-----------------------------------------
DISCLAIMER: This email is bound by the terms and conditions
described at
http://www.key.net/disclaimer.htm
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

James Robertson-7

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Hmm, just this morning I implemented an Opentalk client/server setup -
see:

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=Getting_Remote_Song_Info&entry=3405838719

The code is pretty basic (I have no error checks, which would have to
be there for production code), but it works fine for me on my LAN.

James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library

On Dec 3, 2008, at 8:17 PM, Gregory Bourassa wrote:

> Using Opentalk, we are trying to set up communication between two
> running images on different machines.
>
> The examples in the OpentalkDevGuide book all assume brokers in the
> same
> image on the local machine...and they run fine that way, generally.
> We have managed to communicate between two different images on the
> _same_ machine; but for the same example(s) on two machines, no joy.
>
> One smoking gun is in the STSTRequest>>evaluateFor: method, where it
> calls self validate...so STSTRequest>>validate. This method always
> throws the exception captioned 'The message receiver is not on the
> server'.
>
> All we did was modify the examples from the document to run across two
> machines instead of one. For example on host tweedledee we evaluate
> this in a workspace:
>
> server := RequestBroker newStstTcpAtPort: 4242.
> server start.
>
> Then on host tweedledum we evaluate this:
>
> client := RequestBroker newStstTcpAtPort: 4243.
> client start.
> remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
> remote echo: 'Hello'
>
> This just never works, for the reasons mentioned above -- the
> exception
> purposely raised for the target being remote.
>
> What are we leaving our or doing wrong. It just doesn't seem as
> though
> it should be so hard to modify the examples for multiple machines!
>
> Thanks for any help.
>
> Gregory Bourassa
>
>
>
> -----------------------------------------
> DISCLAIMER: This email is bound by the terms and conditions
> described at
> http://www.key.net/disclaimer.htm
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

giorgiof

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Hi, Gregory.
Never had problems moving from same to different machine.
On my side, I had this message (but this doesn't seems you case) when the remote object was not strongly linked somewhere, and thus being garbaged off. In this case you surely have the same message.

ciao
Giorgio

On Thu, Dec 4, 2008 at 2:17 AM, Gregory Bourassa <[hidden email]> wrote:

Using Opentalk, we are trying to set up communication between two
running images on different machines.

The examples in the OpentalkDevGuide book all assume brokers in the same
image on the local machine...and they run fine that way, generally.
We have managed to communicate between two different images on the
_same_ machine; but for the same example(s) on two machines, no joy.

One smoking gun is in the STSTRequest>>evaluateFor: method, where it
calls self validate...so STSTRequest>>validate. This method always
throws the exception captioned 'The message receiver is not on the server'.

All we did was modify the examples from the document to run across two
machines instead of one. For example on host tweedledee we evaluate
this in a workspace:

server := RequestBroker newStstTcpAtPort: 4242.
server start.

Then on host tweedledum we evaluate this:

client := RequestBroker newStstTcpAtPort: 4243.
client start.
remote := client activeBrokerAtHost: 'tweedledee' port: 4242.
remote echo: 'Hello'

This just never works, for the reasons mentioned above -- the exception
purposely raised for the target being remote.

What are we leaving our or doing wrong. It just doesn't seem as though
it should be so hard to modify the examples for multiple machines!

Thanks for any help.

Gregory Bourassa

-----------------------------------------
DISCLAIMER: This email is bound by the terms and conditions
described at
http://www.key.net/disclaimer.htm
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Gregory Bourassa-3

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Thanks to all who helped us! Especially Martin who put us on the
direct path to the solution.

For the record, the broker was started with newStstTcpAtPort:, which
made it "believe" itself to be on IP address 127.0.0.1 -- at least on
our machines. Using newStstTcpAt: with an explicit IP address fixed the
problem.

When we used this statement, the rest of the example given below worked
perfectly on the first try:

server := RequestBroker newStstTcpAt: (IPSocketAddress hostName:
'172.16.19.17' port: 4242).

Note that, even with this statement, when we use the actual hostname
instead of the dotted-quad address (i.e. 'tweedledee' from my example,
instead of 172.16.19.17), our IP stack still resolves the name to
'127.0.0.1' and the example fails as before.

Thanks again and regards.

Gregory Bourassa
=========================================

Gregory Bourassa wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mike Hales

Re: [vwnc] Opentalk STS across two machines

In reply to this post by kobetic

Martin, I'm dealing with a multi-homed machine right now that is giving me problems. Are there any guidelines and/or code snippets for the best way to deal with this? Can a Broker attach to two interfaces, or should you start a broker on each and export the same objects in both places. It sure would be nice if there were an easy way to get all the ip addresses for a machine built in to Opentalk. The whole roll your own c code, or parse output of ifconfig or ipconfig is really painful.

Mike

On Thu, Dec 4, 2008 at 7:30 AM, <[hidden email]> wrote:

I should add that the 'target' should not be 'remote' by the time the request gets to the #validate method. It should be resolved to a local object during un-marshaling. If it is remote it might be helpful to hook into the localityTest and see why it decides that the target isn't local. One case when you may need to customize the locality test is when you have a host with multiple network interfaces. By default the broker assumes there's only one, so on a multi-homed system it will latch onto the one returned by the DNS lookup. And if there's connection coming through any of the other interfaces, the default locality test is likely to fail those.

HTH,

Martin

[hidden email] wrote:
> The issue is that the broker needs to figure out the IP address of the machine it is running on. Currently we're using reverse DNS for that, i.e. we ask the host for its hostname and then do a reverse lookup with that name. This usually works, but can fail in interesting ways depending on specifics of your network configuration. Take a look at GenericProtocol>>setHost to see what's going on in your case.
>
> HTH,
>
> Martin

--
Mike Hales
Engineering Manager
KnowledgeScape
www.kscape.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

cdavidshaffer

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Gregory Bourassa wrote:

> Thanks to all who helped us! Especially Martin who put us on the
> direct path to the solution.
>
> For the record, the broker was started with newStstTcpAtPort:, which
> made it "believe" itself to be on IP address 127.0.0.1 -- at least on
> our machines. Using newStstTcpAt: with an explicit IP address fixed the
> problem.
>
> When we used this statement, the rest of the example given below worked
> perfectly on the first try:
>
> server := RequestBroker newStstTcpAt: (IPSocketAddress hostName:
> '172.16.19.17' port: 4242).
>
> Note that, even with this statement, when we use the actual hostname
> instead of the dotted-quad address (i.e. 'tweedledee' from my example,
> instead of 172.16.19.17), our IP stack still resolves the name to
> '127.0.0.1' and the example fails as before.
>
> Thanks again and regards.
>
> Gregory Bourassa
> =========================================
>
>

Seems as though you have a solution but it requires a hard-coded
address. If, instead, you'd prefer to use the automatic lookup of the
IP address then these comments might be helpful:

Are you running on a UNIX/Linux machine? If so, what does /etc/hosts
look like? Martin implied that they are doing a reverse DNS lookup but
I'm wondering if they might not be using the UNIX libc
gethostbyname/gethostbyaddr calls. If, indeed, they are using these
system calls then it will typically be the case (depending on the
contents of /etc/nsswitch.conf) that your /etc/hosts file is being
consulted instead of issuing a DNS query. If that's the case then an
entry like this:

127.0.0.1 localhost myhost myhost.mydomain

would cause gethostbyname to return 127.0.0.1 for resolutions of all of
the three named hosts. You can fix this by modifying /etc/hosts to have
separate entries for localhost and your actual host name:

127.0.0.1 localhost
actual.ip.address myhost myhost.mydomain

or, you can drop the "myhost" and "myhost.mydomain" parts of the
original file altogether in which case your system should consult a DNS
server. HTH,

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

cdavidshaffer

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Gregory Bourassa wrote:

kobetic

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Currently a single broker can only manage one listening socket. A socket can be bound either to all available interfaces or to exactly one of them. So those are the main constraints. So unless you use the newTcpSocketAt: API which will make the broker bind to a specific IP, it will be bound to all available interfaces. The latter means the broker will be able to accept connections on all of them, however there's an issue at higher level.

A broker advertises available objects via ObjRefs. Each ObjRef captures an IP address and port number. So any exported ObjRef will point at a specific interface of the host. However if the other side can't reach the host through the specified interface it will have trouble establishing a connection to it.

Another potential issue is the localityTest I mentioned, it's a boolean block that should decide if a given ObjRef is local or remote in relation to a given broker. If you're getting requests refused due the the somewhat strict default test, you can make it more forgiving.

In short, I think you can make a broker run with multiple interfaces in a number of scenarios, but probably not all. Running a broker per interface is probably safer, although that way you can lose identity in the case when the same object gets exported through several brokers with different ObjRefs. Those ObjRefs will compare as different.

It would certainly be nice if Opentalk supported multiple interfaces better, but it is more complicated than just being able to collect the available IPs. We need to detach broker identification from the IP address, i.e. an ObjRef needs to point at a "broker" not an IP. An IP address should be just a hint how to get there if you don't have a route yet, and an ObjRef should be able to care more than just one IP. These changes may require changes in the underlying protocol too and that's another can of worms we have yet to open.

Martin

"Mike Hales"<[hidden email]> wrote:

> Martin, I'm dealing with a multi-homed machine right now that is giving me
> problems. Are there any guidelines and/or code snippets for the best way to
> deal with this? Can a Broker attach to two interfaces, or should you start
> a broker on each and export the same objects in both places. It sure would
> be nice if there were an easy way to get all the ip addresses for a machine
> built in to Opentalk. The whole roll your own c code, or parse output of
> ifconfig or ipconfig is really painful.
> Mike
>
> On Thu, Dec 4, 2008 at 7:30 AM, <[hidden email]> wrote:
>
> > I should add that the 'target' should not be 'remote' by the time the
> > request gets to the #validate method. It should be resolved to a local
> > object during un-marshaling. If it is remote it might be helpful to hook
> > into the localityTest and see why it decides that the target isn't local.
> > One case when you may need to customize the locality test is when you have a
> > host with multiple network interfaces. By default the broker assumes there's
> > only one, so on a multi-homed system it will latch onto the one returned by
> > the DNS lookup. And if there's connection coming through any of the other
> > interfaces, the default locality test is likely to fail those.
> >
> > HTH,
> >
> > Martin
> >
> > [hidden email] wrote:
> > > The issue is that the broker needs to figure out the IP address of the
> > machine it is running on. Currently we're using reverse DNS for that, i.e.
> > we ask the host for its hostname and then do a reverse lookup with that
> > name. This usually works, but can fail in interesting ways depending on
> > specifics of your network configuration. Take a look at
> > GenericProtocol>>setHost to see what's going on in your case.
> > >
> > > HTH,
> > >
> > > Martin
> >
>
> --
> Mike Hales
> Engineering Manager
> KnowledgeScape
> www.kscape.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

kobetic

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

That's exactly what I was going to point out as well. If your hostname resolves to 127.0.0.1 that's most likely a mis-configuration of the host, and you may want to have that fixed. At that point the original example code should start working fine.

Second issue is that if you use the newStstTcpAt: call, it will make the broker bind, and consequently also listen only on that particular IP address. That means you won't be able to reach the broker through 127.0.0.1, or any other interface if there are multiple of those on your host. Note that an interface doesn't have to be a physical network card, these days you can easily find a number of virtual interfaces on a host, which provide access to virtualized OSes, VPN connections, etc. If you use the port based API, that will make the broker listen on all available interfaces. This may not be a problem in your case, but it's good to be aware of that.

HTH,

Martin

"C. David Shaffer"<[hidden email]> wrote:

> Date: December 4, 2008 13:50:59.000
> From: "C. David Shaffer"<[hidden email]>
> To: "Gregory Bourassa"<[hidden email]>
> Cc: [hidden email]
> Subject: Re: [vwnc] Opentalk STS across two machines
>
> Gregory Bourassa wrote:
> > Thanks to all who helped us! Especially Martin who put us on the
> > direct path to the solution.
> >
> > For the record, the broker was started with newStstTcpAtPort:, which
> > made it "believe" itself to be on IP address 127.0.0.1 -- at least on
> > our machines. Using newStstTcpAt: with an explicit IP address fixed the
> > problem.
> >
> > When we used this statement, the rest of the example given below worked
> > perfectly on the first try:
> >
> > server := RequestBroker newStstTcpAt: (IPSocketAddress hostName:
> > '172.16.19.17' port: 4242).
> >
> > Note that, even with this statement, when we use the actual hostname
> > instead of the dotted-quad address (i.e. 'tweedledee' from my example,
> > instead of 172.16.19.17), our IP stack still resolves the name to
> > '127.0.0.1' and the example fails as before.
> >
> > Thanks again and regards.
> >
> > Gregory Bourassa
> > =========================================
> >
> >
> Seems as though you have a solution but it requires a hard-coded
> address. If, instead, you'd prefer to use the automatic lookup of the
> IP address then these comments might be helpful:
>
> Are you running on a UNIX/Linux machine? If so, what does /etc/hosts
> look like? Martin implied that they are doing a reverse DNS lookup but
> I'm wondering if they might not be using the UNIX libc
> gethostbyname/gethostbyaddr calls. If, indeed, they are using these
> system calls then it will typically be the case (depending on the
> contents of /etc/nsswitch.conf) that your /etc/hosts file is being
> consulted instead of issuing a DNS query. If that's the case then an
> entry like this:
>
> 127.0.0.1 localhost myhost myhost.mydomain
>
> would cause gethostbyname to return 127.0.0.1 for resolutions of all of
> the three named hosts. You can fix this by modifying /etc/hosts to have
> separate entries for localhost and your actual host name:
>
> 127.0.0.1 localhost
> actual.ip.address myhost myhost.mydomain
>
> or, you can drop the "myhost" and "myhost.mydomain" parts of the
> original file altogether in which case your system should consult a DNS
> server. HTH,
>
> David
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

thomas.hawker

Re: [vwnc] Opentalk STS across two machines

In reply to this post by kobetic

Martin,

Technically, Opentalk needs a lot more work than that. The particular cases you've cited relating to brokers and ObjRefs are actually issues I've filed Web-Support complaints about. But the real problem is the assumption that brokers and adaptors must use IP addresses at all. While IP-based transport is a wonderful default, there are cases where IP is not used, or at least it is not accessible. There are all sorts of places that use the IP address for identification (where ObjRef is just one of them), which break in ways most unpleasant when you're not actually using IP directly.

In our own case, because we require reliable messaging, we needed to add a wrapper capability to manage message persistence in case of [catastrophic] failure. For enterprise wide interoperability, we chose TIBCO EMS, which is an extension of JMS but contains DLLs accessible from Smalltalk. OpenTalk's implementation and structure don't make it easy to plug into TIBCO or things like it. I can provide you an example of the incredible mess you have to go through just to get around the IP assumptions, for I've written the various broker, adaptor, and transport layer objects to support TIBCO.

Cheers!

Tom Hawker

--------------------------

Senior Framework Developer

--------------------------

Home +1 (408) 274-4128

Office +1 (408) 576-6591

Mobile +1 (408) 835-3643

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Thursday, December 04, 2008 11:15 AM
To: Mike Hales
Cc: [hidden email]
Subject: Re: [vwnc] Opentalk STS across two machines

A broker advertises available objects via ObjRefs. Each ObjRef captures an IP address and port number. So any exported ObjRef will point at a specific interface of the host. However if the other side can't reach the host through the specified interface it will have trouble establishing a connection to it.

Another potential issue is the localityTest I mentioned, it's a boolean block that should decide if a given ObjRef is local or remote in relation to a given broker. If you're getting requests refused due the the somewhat strict default test, you can make it more forgiving.

In short, I think you can make a broker run with multiple interfaces in a number of scenarios, but probably not all. Running a broker per interface is probably safer, although that way you can lose identity in the case when the same object gets exported through several brokers with different ObjRefs. Those ObjRefs will compare as different.

It would certainly be nice if Opentalk supported multiple interfaces better, but it is more complicated than just being able to collect the available IPs. We need to detach broker identification from the IP address, i.e. an ObjRef needs to point at a "broker" not an IP. An IP address should be just a hint how to get there if you don't have a route yet, and an ObjRef should be able to care more than just one IP. These changes may require changes in the underlying protocol too and that's another can of worms we have yet to open.

Martin

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not intended for you, please delete it immediately unread.  The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so.  Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email.  Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Gregory Bourassa-3

Re: [vwnc] Opentalk STS across two machines

In reply to this post by cdavidshaffer

Thanks, David,

You have described exactly what is happening on our systems, which are Linux. We experimented with removing the alias (myhost, in your example) from the localhost line, and that worked. Alert for anyone testing this -- we had to restart our image to get it to pick up the change.

Regards.

Gregory Bourassa

C. David Shaffer wrote:

Gregory Bourassa wrote:

Thanks to all who helped us!   Especially Martin who put us on the 
direct path to the solution.

For the record,  the broker was started with newStstTcpAtPort:,  which 
made it "believe" itself to be on IP address 127.0.0.1 -- at least on 
our machines.  Using newStstTcpAt: with an explicit IP address fixed the 
problem.  

When we used this statement,  the rest of the example given below worked 
perfectly on the first try:

    server := RequestBroker newStstTcpAt: (IPSocketAddress hostName: 
'172.16.19.17' port: 4242).

Note that, even with this statement, when we use the actual hostname 
instead of the dotted-quad address (i.e. 'tweedledee' from my example, 
instead of 172.16.19.17),  our IP stack still resolves the name to 
'127.0.0.1' and the example fails as before.

Thanks again and regards.

Gregory Bourassa
=========================================

Seems as though you have a solution but it requires a hard-coded
address.  If, instead, you'd prefer to use the automatic lookup of the
IP address then these comments might be helpful:

Are you running on a UNIX/Linux machine?  If so, what does /etc/hosts
look like?  Martin implied that they are doing a reverse DNS lookup but
I'm wondering if they might not be using the UNIX libc
gethostbyname/gethostbyaddr calls.  If, indeed, they are using these
system calls then it will typically be the case (depending on the
contents of /etc/nsswitch.conf) that your /etc/hosts file is being
consulted instead of issuing a DNS query.  If that's the case then an
entry like this:

127.0.0.1  localhost myhost myhost.mydomain

would cause gethostbyname to return 127.0.0.1 for resolutions of all of
the three named hosts.  You can fix this by modifying /etc/hosts to have
separate entries for localhost and your actual host name:

127.0.0.1 localhost
actual.ip.address myhost myhost.mydomain

or, you can drop the "myhost" and "myhost.mydomain" parts of the
original file altogether in which case your system should consult a DNS
server.  HTH,

David

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

kobetic

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Tom,

Yes, there's still a lot to do to fulfill our ambitions with Opentalk. I'm certainly not surprised that a non-IP transport would be difficult to do. Unfortunately at this point we have our own fairly long laundry list even for the IP based world. Hopefully one day :-). But at least for what it does today it seems to do reasonably well. It's seeing quite a bit of use in its various flavours (STST, HTTP/WebServices, HTTP/Seaside). It's a lot of ground to cover and there's still a lot to improve in just those areas.

I'd certainly be interested to see what you did with the non-IP transports, we might be able to incorporate at least some of the changes you had to make. But I don't see us pushing for non-IP protocols any time soon.

Cheers,

Martin

<[hidden email]> wrote:

> Technically, Opentalk needs a lot more work than that. The particular cases you've cited relating to brokers and ObjRefs are actually issues I've filed Web-Support complaints about. But the real problem is the assumption that brokers and adaptors must use IP addresses at all. While IP-based transport is a wonderful default, there are cases where IP is not used, or at least it is not accessible. There are all sorts of places that use the IP address for identification (where ObjRef is just one of them), which break in ways most unpleasant when you're not actually using IP directly.
>
>
>
> In our own case, because we require reliable messaging, we needed to add a wrapper capability to manage message persistence in case of [catastrophic] failure. For enterprise wide interoperability, we chose TIBCO EMS, which is an extension of JMS but contains DLLs accessible from Smalltalk. OpenTalk's implementation and structure don't make it easy to plug into TIBCO or things like it. I can provide you an example of the incredible mess you have to go through just to get around the IP assumptions, for I've written the various broker, adaptor, and transport layer objects to support TIBCO.
>
>
>
> Cheers!
>
>
>
> Tom Hawker
>
> --------------------------
>
> Senior Framework Developer
>
> --------------------------
>
> Home +1 (408) 274-4128
>
> Office +1 (408) 576-6591
>
> Mobile +1 (408) 835-3643
>
>
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: Thursday, December 04, 2008 11:15 AM
> To: Mike Hales
> Cc: [hidden email]
> Subject: Re: [vwnc] Opentalk STS across two machines
>
>
>
> Currently a single broker can only manage one listening socket. A socket can be bound either to all available interfaces or to exactly one of them. So those are the main constraints. So unless you use the newTcpSocketAt: API which will make the broker bind to a specific IP, it will be bound to all available interfaces. The latter means the broker will be able to accept connections on all of them, however there's an issue at higher level.
>
>
>
> A broker advertises available objects via ObjRefs. Each ObjRef captures an IP address and port number. So any exported ObjRef will point at a specific interface of the host. However if the other side can't reach the host through the specified interface it will have trouble establishing a connection to it.
>
>
>
> Another potential issue is the localityTest I mentioned, it's a boolean block that should decide if a given ObjRef is local or remote in relation to a given broker. If you're getting requests refused due the the somewhat strict default test, you can make it more forgiving.
>
>
>
> In short, I think you can make a broker run with multiple interfaces in a number of scenarios, but probably not all. Running a broker per interface is probably safer, although that way you can lose identity in the case when the same object gets exported through several brokers with different ObjRefs. Those ObjRefs will compare as different.
>
>
>
> It would certainly be nice if Opentalk supported multiple interfaces better, but it is more complicated than just being able to collect the available IPs. We need to detach broker identification from the IP address, i.e. an ObjRef needs to point at a "broker" not an IP. An IP address should be just a hint how to get there if you don't have a route yet, and an ObjRef should be able to care more than just one IP. These changes may require changes in the underlying protocol too and that's another can of worms we have yet to open.
>
>
>
> Martin
>
>
>
> IMPORTANT NOTICE
> Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

thomas.hawker

Re: [vwnc] Opentalk STS across two machines

In reply to this post by Gregory Bourassa-3

Martin,

I think one of your original ideas, that ObjRefs be associated with a broker and an object id, is a good start – just make sure you support synonyms [a different issue]. An exported object should be independent of the particular transport(s) over which its broker communicates. This leads to an obvious restructuring – brokers don't have and shouldn't be known by IP addresses, rather they or their adaptors have connections. Both brokers and adaptors must avoid assuming such connections are IP-based. The connection creates a transport when necessary by use and context. While a connection may have an IP access point (see below), only an IP-based transport should use its IP address for identification. The obvious issue here is how you start up and configure different types of transports, but that is in most ways handled by the Configuration hierarchy, which contains the various details. I have no problem with OpenTalk having an IP-specific hierarchy, but I think that should be the refinement, not the generality. In this case, an IP “connection” would pretty much be a null object. I’m not even sure that it should hold on to an IP address!

In saying this, I think the concepts of “connection” and “broker” are a bit overused. I will call systems like MQ Series and TIBCO EMS message agent systems, avoiding the word "broker" (even thought that's what the agent is doing). In a message agent-based implementation, you must “attach” to the agent server, typically called (in the agent’s language) a “connection.” This often has the form of an access point, basically an IP address and port or other explicit transport URL, and usually implements authorization restrictions (that is, you supply a user name and password to establish the connection). You then have individual transports which talk to a particular message channel as implemented by the underlying agent software.

In EMS, you log in to the agent server and then open a transport to a particular queue or topic. Each queue or topic you access may in fact be served by a different agent server, necessitating support for multiple connections. A new transport is required for each queue or topic accessed or each separate server “thread” that will be run. An agent transport is like a TCP socket – it stays around forever. I implemented usage delays so that things clean up after some period of inactivity. Also, a transport is unidirectional: it only reads or writes and does so to one and only one channel. (Turn-around or message reply semantics are handled internally through temporary channels.) Some cases like EMS support factories for connections and transports. This is important with transaction-based semantics, where read or write actions are tied via 2-phase commit with other changes, such as database updates. I didn't try to handle that stuff.

Cheers!

Tom Hawker
Senior Framework Developer
Home	+1 (408) 274-4128
Office	+1 (408) 576-6591
Mobile	+1 (408) 835-3643

From: [hidden email] [mailto:[hidden email]]

Sent: Thursday, December 04, 2008 2:53 PM

To: THOMAS HAWKER (DEV-ISDC-OUI/SNT)

Cc: [hidden email]

Subject: Re: RE: [vwnc] Opentalk STS across two machines

Tom,

Yes, there's still a lot to do to fulfill our ambitions with Opentalk. I'm certainly not surprised that a non-IP transport would be difficult to do. Unfortunately at this point we have our own fairly long laundry list even for the IP based world. Hopefully one day :-). But at least for what it does today it seems to do reasonably well. It's seeing quite a bit of use in its various flavours (STST, HTTP/WebServices, HTTP/Seaside). It's a lot of ground to cover and there's still a lot to improve in just those areas.

I'd certainly be interested to see what you did with the non-IP transports, we might be able to incorporate at least some of the changes you had to make. But I don't see us pushing for non-IP protocols any time soon.

Cheers,

Martin

<[hidden email]> wrote:

> In our own case, because we require reliable messaging, we needed to add a wrapper capability to manage message persistence in case of [catastrophic] failure. For enterprise wide interoperability, we chose TIBCO EMS, which is an extension of JMS but contains DLLs accessible from Smalltalk. OpenTalk's implementation and structure don't make it easy to plug into TIBCO or things like it. I can provide you an example of the incredible mess you have to go through just to get around the IP assumptions, for I've written the various broker, adaptor, and transport layer objects to support TIBCO.

> Cheers!

> Tom Hawker

> --------------------------

> Senior Framework Developer

> --------------------------

> Home +1 (408) 274-4128

> Office +1 (408) 576-6591

> Mobile +1 (408) 835-3643

> -----Original Message-----

> From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]

> Sent: Thursday, December 04, 2008 11:15 AM

> To: Mike Hales

> Cc: [hidden email]

> Subject: Re: [vwnc] Opentalk STS across two machines

> Currently a single broker can only manage one listening socket. A socket can be bound either to all available interfaces or to exactly one of them. So those are the main constraints. So unless you use the newTcpSocketAt: API which will make the broker bind to a specific IP, it will be bound to all available interfaces. The latter means the broker will be able to accept connections on all of them, however there's an issue at higher level.

> A broker advertises available objects via ObjRefs. Each ObjRef captures an IP address and port number. So any exported ObjRef will point at a specific interface of the host. However if the other side can't reach the host through the specified interface it will have trouble establishing a connection to it.

> Another potential issue is the localityTest I mentioned, it's a boolean block that should decide if a given ObjRef is local or remote in relation to a given broker. If you're getting requests refused due the the somewhat strict default test, you can make it more forgiving.

> In short, I think you can make a broker run with multiple interfaces in a number of scenarios, but probably not all. Running a broker per interface is probably safer, although that way you can lose identity in the case when the same object gets exported through several brokers with different ObjRefs. Those ObjRefs will compare as different.

> It would certainly be nice if Opentalk supported multiple interfaces better, but it is more complicated than just being able to collect the available IPs. We need to detach broker identification from the IP address, i.e. an ObjRef needs to point at a "broker" not an IP. An IP address should be just a hint how to get there if you don't have a route yet, and an ObjRef should be able to care more than just one IP. These changes may require changes in the underlying protocol too and that's another can of worms we have yet to open.

> Martin

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not intended for you, please delete it immediately unread.  The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so.  Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email.  Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc