Smalltalk › Cincom › VisualWorks

[vwnc] opentalk & connections

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Mark Plas

[vwnc] opentalk & connections

Hello,

I have a question regarding Opentalk.

This is an example from the Opentalk documentation:

| server client str remoteStr size |

server := RequestBroker newStstTcpAtPort: 4242.

client := RequestBroker newStstTcpAtPort: 4243.

[ server start.

client start.

str := 'Hello'.

server objectAdaptor export: str oid: #Greeting.

remoteStr := client remoteObjectToHost: 'localhost' port: 4242

oid: #Greeting.

size := remoteStr size.

(size = str size)

ifTrue: [Transcript show: 'Correct! ']

ifFalse: [Transcript show: 'Incorrect! '].

] ensure: [server stop. client stop]

I notice when the server & client are started two SocketAccessors are instantiated.

Then, when I send #size to removeStr, other SocketAccessors are created, which is fine.

But these new connections remain alive until I stop the client&server. I want to have a mechanism with which I can briefly connect to a remote host, send a message, and then close the connection to that host, without stopping my request broker. Is this possible?

Thanks,

Mark

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

kobetic

Re: [vwnc] opentalk & connections

There's isn't direct API to control individual connections, although you could dig into the broker get the corresponding TCPTransport object and tell it to #stop. Connection lifetime is maintained automatically and they are shut down after a period of innactivity. The expiration time is controlled by the ConnectionAdaptorConfiguration>>connectionTimeout: parameter (in milliseconds), so you could set it sufficiently low to get the desired effect. Note however that you probably don't want the connection to shut-down before it manages to receive the reply. So setting connectionTimeout: lower than BrokerConfiguration>>requestTimeout: might create some issues, likely depending on your network configuration.

Another alternative is using a UDP broker instead. UDP protocol doesn't use connections, the same port sends and receives packets to/from anywhere. Note however that UDP protocol is deemed unreliable, because it doesn't have the same retransmission capabilities built in as TCP, however in practice, especially on LANs, it should be reliable enough for many applications. There's also an Opentalk limitation of UDP brokers which caps the maximum size of the individual messages (currently set to 4K of the full marshalled size, see UDPTransport>>maxPackageSize). You might be able to increase the limit, although unfortunately it is currently not exposed as configurable parameter, so you'll just have to override the #maxPackageSize method.

HTH,

Martin

"Mark Plas"<[hidden email]> wrote:

> Date: November 14, 2008 7:43:45.000
> From: "Mark Plas"<[hidden email]>
> To: "[hidden email]"<[hidden email]>
> Subject: [vwnc] opentalk & connections
>
> Hello,
>
> I have a question regarding Opentalk.
>
> This is an example from the Opentalk documentation:
>
> | server client str remoteStr size |
> server := RequestBroker newStstTcpAtPort: 4242.
> client := RequestBroker newStstTcpAtPort: 4243.
> [ server start.
> client start.
> str := 'Hello'.
> server objectAdaptor export: str oid: #Greeting.
> remoteStr := client remoteObjectToHost: 'localhost' port: 4242
> oid: #Greeting.
> size := remoteStr size.
> (size = str size)
> ifTrue: [Transcript show: 'Correct! ']
> ifFalse: [Transcript show: 'Incorrect! '].
> ] ensure: [server stop. client stop]
>
> I notice when the server & client are started two SocketAccessors are instantiated.
> Then, when I send #size to removeStr, other SocketAccessors are created, which is fine.
>
> But these new connections remain alive until I stop the client&server. I want to have a mechanism with which I can briefly connect to a remote host, send a message, and then close the connection to that host, without stopping my request broker. Is this possible?
>
> Thanks,
> Mark
>
> _______________________________________________
> 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 & connections

In reply to this post by Mark Plas

Hi Martin, thanks for the detailed answer. This should get me on track.

Best regards,
Mark

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: vrijdag 14 november 2008 14:58
To: Mark Plas
Cc: [hidden email]
Subject: Re: [vwnc] opentalk & connections

There's isn't direct API to control individual connections, although you could dig into the broker get the corresponding TCPTransport object and tell it to #stop. Connection lifetime is maintained automatically and they are shut down after a period of innactivity. The expiration time is controlled by the ConnectionAdaptorConfiguration>>connectionTimeout: parameter (in milliseconds), so you could set it sufficiently low to get the desired effect. Note however that you probably don't want the connection to shut-down before it manages to receive the reply. So setting connectionTimeout: lower than BrokerConfiguration>>requestTimeout: might create some issues, likely depending on your network configuration.

Another alternative is using a UDP broker instead. UDP protocol doesn't use connections, the same port sends and receives packets to/from anywhere. Note however that UDP protocol is deemed unreliable, because it doesn't have the same retransmission capabilities built in as TCP, however in practice, especially on LANs, it should be reliable enough for many applications. There's also an Opentalk limitation of UDP brokers which caps the maximum size of the individual messages (currently set to 4K of the full marshalled size, see UDPTransport>>maxPackageSize). You might be able to increase the limit, although unfortunately it is currently not exposed as configurable parameter, so you'll just have to override the #maxPackageSize method.

HTH,

Martin

"Mark Plas"<[hidden email]> wrote:

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