Smalltalk › Instantiations

how Tor find out if port is in use?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

jtuchel

how Tor find out if port is in use?

hi

I wonder if there is a portable way to find out at image startup if a certain tcp/ip port is already in use on this machine.

Right now, if I start up my test app in parallel to the development image, I often don't realize I am talking to the image (because it has been using the port in the first place) rather than the run time image.

I'd also like to be able to log an error if a server image is started but cannot use a certain port.

Any ideas?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Marten Feldtmann-2

Re: how Tor find out if port is in use?

I would think, that binding to a port a second time will result in an error ...

Thomas Koschate-2

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

On Friday, April 19, 2013 1:35:23 PM UTC-4, [hidden email] wrote:

I wonder if there is a portable way to find out at image startup if a certain tcp/ip port is already in use on this machine.

I actually had to do something like that for TAF. In our case, we had to restrict clients to using a certain port range to avoid the negative impact of security scans, but because we launch multiple ports, we have to make sure that we're not trying to grab a port already in use.

This code fragment, from a subclass of SstTcpSocketPair, should help you:

    System gdkPortRange do: [:portIndex |
        (serverPort :=
            aListeningSocket bind: (
                (SciSocketAddress family: AFINET)
                    address: INADDRANY;
                    port: portIndex;
                    yourself))
                        isSciError
                            ifFalse: [^serverPort]].
    ^serverPort

The #gdkPortRange answers a range of possible ports to be used, and we keep testing until we find one that doesn't raise an SciError when we attempt to bind to the port.

This is not foolproof - it's possible that some other process running on the machine might grab that port after we've decided it's safe to use, but it's the best I've been able to come up with.

Tom

Thomas Koschate-2

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

On Friday, April 19, 2013 1:35:23 PM UTC-4, [hidden email] wrote:

I'd also like to be able to log an error if a server image is started but cannot use a certain port.

I should also point out that TobSockets will raise an exception if you attempt to start a server on a port in use, and it uses a mechanism similar to the one I outlined in my other post.

Tom

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by Marten Feldtmann-2

Marten,

maybe it does, but it doesn't throw an exception. When I saw tom's snippet I immediately banged my head to the wall. How could I forget about the is... error checks in vast!

I will have to check.

Joachim

Am Freitag, 19. April 2013 20:22:52 UTC+2 schrieb Marten Feldtmann:

I would think, that binding to a port a second time will result in an error ...

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by Thomas Koschate-2

Hi Tom,

thanks a lot for this snippet. I will see how I can adapt it to my high-level use case. By high level I mean that I am not opening a port directly, but start a WASstServerAdapter. This adapter does not throw an exception if the port is taken. But maybe it just returns the SciError it gets from the bind call. I don't check the return value of WASstServerAdaptor>>#open, but maybe I should..

Joachim

Am Freitag, 19. April 2013 21:23:57 UTC+2 schrieb Thomas Koschate:

On Friday, April 19, 2013 1:35:23 PM UTC-4, [hidden email] wrote:

I wonder if there is a portable way to find out at image startup if a certain tcp/ip port is already in use on this machine.

I actually had to do something like that for TAF. In our case, we had to restrict clients to using a certain port range to avoid the negative impact of security scans, but because we launch multiple ports, we have to make sure that we're not trying to grab a port already in use.

This code fragment, from a subclass of SstTcpSocketPair, should help you:

    System gdkPortRange do: [:portIndex |
        (serverPort :=
            aListeningSocket bind: (
                (SciSocketAddress family: AFINET)
                    address: INADDRANY;
                    port: portIndex;
                    yourself))
                        isSciError
                            ifFalse: [^serverPort]].
    ^serverPort

The #gdkPortRange answers a range of possible ports to be used, and we keep testing until we find one that doesn't raise an SciError when we attempt to bind to the port.

This is not foolproof - it's possible that some other process running on the machine might grab that port after we've decided it's safe to use, but it's the best I've been able to come up with.

Tom

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

Hi again,

I finally had the time to look into this a little more.

So my basic problem is that when I deploy a new image version to a headless linux server and forget to kill the running process before starting the new image, I will get no error or anything, but the new image will not respond to Browser requests.

Here is how to easily try what I mean:

(WASstServerAdaptor port: 8080) start.
(WASstServerAdaptor port: 8080) start.

Inspecting the result of the second line will simply work, and in the Seaside Control panel you see two Adaptors, one of which isn't running (maybe that is where I need to dig deeper). So I neither get an exception nor an SciError.

I think that is not good behaviour. I somehow feel I should be warned by the system that a new Adaptor is now configured to listen to a port that is already being listened to.
I can check an adaptor if it #isRunning, so this is probably the way to check if my server could be started. At least I will use this for now.

Somehow I think it feels wrong. I created an Adaptor and asked it to start, but it didn't actually start - without telling me. Shouldn't this lead to an Exception or at least a Warning that I can choose to ignore? I mean, I asked it to START, meaning to be ready and answer requests. But it isn't....

What do others think? What does Instantiations think? Is there some reason to handle things like that because it is the way SST has worked for decades now? Or has this just be overseen?

Joachim

Am Freitag, 19. April 2013 19:35:23 UTC+2 schrieb [hidden email]:

hi

I wonder if there is a portable way to find out at image startup if a certain tcp/ip port is already in use on this machine.

Right now, if I start up my test app in parallel to the development image, I often don't realize I am talking to the image (because it has been using the port in the first place) rather than the run time image.

I'd also like to be able to log an error if a server image is started but cannot use a certain port.

Any ideas?

Joachim

jtuchel

Re: how Tor find out if port is in use?

Just to clarify a bit:

here is the code I had so far and that I thought would be fine:

    [
        (WASstServerAdaptor port: self port) start.
        EsLogManager info: 'WASStServerAdaptor started on port: ' , port asString]
            on: Error
            do: [:ex |
                EsLogManager
                    error: 'Seaside Adaptor couldn''t start due to: ' , ex description.
                ex pass]

But in fact I never get an error if the port is in use already. Everything looks fine after this method executed.
Am I misunderstanding something and it is in theory okay to add another Adaptor to a port that has a listener? I'd be surprised because the results of contacting a port would be quite unpredictable...

As it stands now, I have to add some additional code to check the adaptor whether it isRunning, maybe even wait a second because starting may take a moment, or wait if it #isStarting until it is not #isStarting anymore and the check if it #isRunning. Is that the way it should be? Is there a good reason for this? If not, I suggest throwing an exception in #start.

Joachim

Am Mittwoch, 24. April 2013 10:15:40 UTC+2 schrieb [hidden email]:

Hi again,

I finally had the time to look into this a little more.

So my basic problem is that when I deploy a new image version to a headless linux server and forget to kill the running process before starting the new image, I will get no error or anything, but the new image will not respond to Browser requests.

Here is how to easily try what I mean:

(WASstServerAdaptor port: 8080) start.
(WASstServerAdaptor port: 8080) start.

Inspecting the result of the second line will simply work, and in the Seaside Control panel you see two Adaptors, one of which isn't running (maybe that is where I need to dig deeper). So I neither get an exception nor an SciError.

I think that is not good behaviour. I somehow feel I should be warned by the system that a new Adaptor is now configured to listen to a port that is already being listened to.
I can check an adaptor if it #isRunning, so this is probably the way to check if my server could be started. At least I will use this for now.

Somehow I think it feels wrong. I created an Adaptor and asked it to start, but it didn't actually start - without telling me. Shouldn't this lead to an Exception or at least a Warning that I can choose to ignore? I mean, I asked it to START, meaning to be ready and answer requests. But it isn't....

What do others think? What does Instantiations think? Is there some reason to handle things like that because it is the way SST has worked for decades now? Or has this just be overseen?

Joachim

Am Freitag, 19. April 2013 19:35:23 UTC+2 schrieb [hidden email]:
hi

I wonder if there is a portable way to find out at image startup if a certain tcp/ip port is already in use on this machine.

Right now, if I start up my test app in parallel to the development image, I often don't realize I am talking to the image (because it has been using the port in the first place) rather than the run time image.

I'd also like to be able to log an error if a server image is started but cannot use a certain port.

Any ideas?

Joachim

Thomas Koschate-2

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

On Wednesday, April 24, 2013 4:15:40 AM UTC-4, [hidden email] wrote:

What do others think? What does Instantiations think? Is there some reason to handle things like that because it is the way SST has worked for decades now? Or has this just be overseen?

I agree - this behavior is less than desirable. We've lived with it for the last 13 years or so, but I guess we're lazy. Each of the developers here will start an environment on AIX that will consume dozens of ports, but we've learned to use assigned ranges for our public ports. However, every once in a while, one of the system generated ports will grab another developer's port before they've launched, and much hilarity ensues as we fail to notice at first, and then try to figure out who the culprit is when a system doesn't start.

It would be good if an exception were raised, like the TobSockets raises when a port is in use.

Tom

Marten Feldtmann-2

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

The reason for this behaviour is located in the method: SstTcpTransport>>#basicOpenListeningSocket and it seems to be correctly handled by VASmalltalk.

In this method a socket option ("SOREUSEADDR") is set to true (if the configuration of the tcp network allows it, which is normally the case of VASmalltalk).

Actually I would wish, that the Seaside control panel (or its non-gui manager) should create its own (Sst) TCP transport configuration and set this option to false - perhaps even use the SOEXCLUSIVEADDRUSE option to make it more secure (but this option is not available under XP) and should use this new configuration to configure its sockets.

If you do not set this option you get the error you might expect ...

All the error checking (add another server adaptor) is done high-level oriented in VA - actually they should allow to create the server adaptors without error checking and just rely on the SstError returned by low leved methods.

Actually I was not aware, that this is handled in that way by VA - but Joachims posting forces me to look for the reasons.

And microsoft says:

"The SO_REUSEADDR socket option allows a socket to forcibly bind to a port in use by another socket."

Marten Feldtmann-2

Re: how Tor find out if port is in use?

Just to make this clearer: this is the default behaviour for the "http:" configuration (and perhaps others) within VASmalltalk. You can change this by changing the method SstHttpCommunications class>>serverTransportConfiguration (global).

Marten

Am Mittwoch, 24. April 2013 11:51:21 UTC+2 schrieb Marten Feldtmann:

The reason for this behaviour is located in the method: SstTcpTransport>>#basicOpenListeningSocket and it seems to be correctly handled by VASmalltalk.

In this method a socket option ("SOREUSEADDR") is set to true (if the configuration of the tcp network allows it, which is normally the case of VASmalltalk).

Actually I would wish, that the Seaside control panel (or its non-gui manager) should create its own (Sst) TCP transport configuration and set this option to false - perhaps even use the SOEXCLUSIVEADDRUSE option to make it more secure (but this option is not available under XP) and should use this new configuration to configure its sockets.

If you do not set this option you get the error you might expect ...

All the error checking (add another server adaptor) is done high-level oriented in VA - actually they should allow to create the server adaptors without error checking and just rely on the SstError returned by low leved methods.

Actually I was not aware, that this is handled in that way by VA - but Joachims posting forces me to look for the reasons.

And microsoft says:

"The SO_REUSEADDR socket option allows a socket to forcibly bind to a port in use by another socket."

Wayne Johnston

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

The great Bob Brodd wrote to me (INST50097):

We currently do not support this setting in VA Smalltalk, but here is how you can set it. Once you have a handle to the socket, before binding to it , execute the following snippet of code:

self setSockOpt: (SOREUSEADDR bitInvert) optionValue: true. "Exclusive Use"

You may want to modify the base method SstTcpTransport>>#basicOpenListeningSocket for now my hardcoding the setting of this value for your situation. You just want to avoid setting exclusive use on and reuse address on as well as they are incompatible settings. Here is something you can try out .. see italic part for my addition:

basicOpenListeningSocket

"Open a server socket bound to the address associated with the receiver's endpoint.

Answer an SstError on error."

| socket result |

(socket := configuration socketClass socket: AFINET type: SOCKSTREAM protocol: IP) isSciError

ifTrue: [^SstError for: SstInternalTransportError with: socket].

"Set socket to exclusive use unless reuseAddress is set to true "

( configuration reuseAddress == true )

ifFalse: [ socket setSockOpt: (SOREUSEADDR bitInvert) optionValue: true ].

((configuration reuseAddress == true

and: [(result := socket setSockOpt: SOREUSEADDR optionValue: true) isSciError])

or: [

(result := socket bind: self endpoint address sstTransportAddress) isSciError or: [

configuration allowIncomingConnections

and: [(result := socket listen: configuration listenBacklog) isSciError]]])

ifTrue: [

socket close.

^SstError for: SstInternalTransportError with: result].

^socket

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by Marten Feldtmann-2

Wow, Marten,

thanks for digging down there ;-)

So this is just some misconception on my side, because IBM wanted to open a listening socket with reusing an address. And me, I expect something else here. So the discussion now should be:

Does socket reuse make sense for a Seaside Application?

I don't think so, and the fact that a WASstServerAdaptor says it is not running if it is started on a used port seems to indicate I am not completely off the tracks.

Is VA's behaviour wrong. Seems it isn't entirely, because what I ask it for (without knowing) is to start an adaptor on a port and not worry if it is already in use. So I can now follow the advice of Bob (thanks, Wayne for your post) and change some deep low-level method in SstTcpTransport - which may have very interesting side effects if I use more than just Seaside - who knows why and what for IBM once decided to open a listening socket with SOREUSEADDR, or handle the situation somewhere in my application code (you can see here what I decided to do for now and some more background info on the problem).

Or I can ask Instantiations to take a second look at WASstServerAdaptor and see if adding an exception on this level makes sense. Which means the low-level socket stuff wouldn't have to be changed but a Seaside user would know something's wrong.

Hmmm. I guess we need some TCP/IP cracks to tell us more about what's right and wrong. The way it is right now is wrong in my opinion, but only for Seaside, I cannot judge if any level deeper the existing behavior makes sense. And I don't have time and energy to try and collect information about this.

For now, I've found a workaround that does the job. But it's really just a dirty hack on the surface.

Joachim

P.S. I have to apaologize for the misleading title of this thread. I wanted to talk about WASstServerAdaptor right from the start but first thought I have to check for the availability of the port first. Now, after a few days, I am sure that would work, but would only be a workaround with lots of more (ugly) code than the one I chose to use

Am Mittwoch, 24. April 2013 11:51:21 UTC+2 schrieb Marten Feldtmann:

The reason for this behaviour is located in the method: SstTcpTransport>>#basicOpenListeningSocket and it seems to be correctly handled by VASmalltalk.

In this method a socket option ("SOREUSEADDR") is set to true (if the configuration of the tcp network allows it, which is normally the case of VASmalltalk).

Actually I would wish, that the Seaside control panel (or its non-gui manager) should create its own (Sst) TCP transport configuration and set this option to false - perhaps even use the SOEXCLUSIVEADDRUSE option to make it more secure (but this option is not available under XP) and should use this new configuration to configure its sockets.

If you do not set this option you get the error you might expect ...

All the error checking (add another server adaptor) is done high-level oriented in VA - actually they should allow to create the server adaptors without error checking and just rely on the SstError returned by low leved methods.

Actually I was not aware, that this is handled in that way by VA - but Joachims posting forces me to look for the reasons.

And microsoft says:

"The SO_REUSEADDR socket option allows a socket to forcibly bind to a port in use by another socket."

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by Wayne Johnston

Wayne,

thanks for sharing.

The problem with the solution suggested here is that I cannot tell if I break something for other uses of TCP/IP sockets if I change such a low level method. What if I need to listen to other ports for web sockets or some IPC stuff? So I'll not touch that code and just say it makes no sense in the very specific scenario I describe here (starting a Seaside Adaptor).

For now, I have a workaround and will keep it like that. I hope Instantiations will give this whole thing another thought once they work on SST.

Joachim

Am Mittwoch, 24. April 2013 14:41:20 UTC+2 schrieb Wayne Johnston:

The great Bob Brodd wrote to me (INST50097):

We currently do not support this setting in VA Smalltalk, but here is how you can set it. Once you have a handle to the socket, before binding to it , execute the following snippet of code:

self setSockOpt: (SOREUSEADDR bitInvert) optionValue: true. "Exclusive Use"

You may want to modify the base method SstTcpTransport>>#basicOpenListeningSocket for now my hardcoding the setting of this value for your situation. You just want to avoid setting exclusive use on and reuse address on as well as they are incompatible settings. Here is something you can try out .. see italic part for my addition:

basicOpenListeningSocket

"Open a server socket bound to the address associated with the receiver's endpoint.

Answer an SstError on error."

| socket result |

(socket := configuration socketClass socket: AFINET type: SOCKSTREAM protocol: IP) isSciError

ifTrue: [^SstError for: SstInternalTransportError with: socket].

"Set socket to exclusive use unless reuseAddress is set to true "

( configuration reuseAddress == true )

ifFalse: [ socket setSockOpt: (SOREUSEADDR bitInvert) optionValue: true ].

((configuration reuseAddress == true

and: [(result := socket setSockOpt: SOREUSEADDR optionValue: true) isSciError])

or: [

(result := socket bind: self endpoint address sstTransportAddress) isSciError or: [

configuration allowIncomingConnections

and: [(result := socket listen: configuration listenBacklog) isSciError]]])

ifTrue: [

socket close.

^SstError for: SstInternalTransportError with: result].

^socket

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

My workaround doesn't work on Linux :(

The log output I get on Linux is this:

'2013-04-24 17:32:48,917: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:49,519: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:50,121: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:50,723: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:51,325: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:51,927: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:52,529: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:53,131: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:53,732: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:54,334: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:54,936: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:55,538: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:56,140: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:56,742: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:57,343: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:57,945: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:58,647: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:59,249: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:32:59,851: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:00,453: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:01,054: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:01,656: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:02,258: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:02,860: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:03,462: [INFO] Waiting for the Adapter to finish starting'

'2013-04-24 17:33:04,064: [INFO] Waiting for the Adapter to finish starting'

So this means the WASstServerAdaptor doesn't give up trying to start while on Windows I almost immediately get the exception I'm throwing. So my workaround code has to get even uglier. I will introduce a number of maximum retries before I throw an exception... You can probably see why I'd like to get an exception ;-)

Am Mittwoch, 24. April 2013 15:08:04 UTC+2 schrieb [hidden email]:

Wow, Marten,

thanks for digging down there ;-)

So this is just some misconception on my side, because IBM wanted to open a listening socket with reusing an address. And me, I expect something else here. So the discussion now should be:

Does socket reuse make sense for a Seaside Application?

I don't think so, and the fact that a WASstServerAdaptor says it is not running if it is started on a used port seems to indicate I am not completely off the tracks.

Is VA's behaviour wrong. Seems it isn't entirely, because what I ask it for (without knowing) is to start an adaptor on a port and not worry if it is already in use. So I can now follow the advice of Bob (thanks, Wayne for your post) and change some deep low-level method in SstTcpTransport - which may have very interesting side effects if I use more than just Seaside - who knows why and what for IBM once decided to open a listening socket with SOREUSEADDR, or handle the situation somewhere in my application code (you can see here what I decided to do for now and some more background info on the problem).

Or I can ask Instantiations to take a second look at WASstServerAdaptor and see if adding an exception on this level makes sense. Which means the low-level socket stuff wouldn't have to be changed but a Seaside user would know something's wrong.

Hmmm. I guess we need some TCP/IP cracks to tell us more about what's right and wrong. The way it is right now is wrong in my opinion, but only for Seaside, I cannot judge if any level deeper the existing behavior makes sense. And I don't have time and energy to try and collect information about this.

For now, I've found a workaround that does the job. But it's really just a dirty hack on the surface.

Joachim

P.S. I have to apaologize for the misleading title of this thread. I wanted to talk about WASstServerAdaptor right from the start but first thought I have to check for the availability of the port first. Now, after a few days, I am sure that would work, but would only be a workaround with lots of more (ugly) code than the one I chose to use

Am Mittwoch, 24. April 2013 11:51:21 UTC+2 schrieb Marten Feldtmann:
The reason for this behaviour is located in the method: SstTcpTransport>>#basicOpenListeningSocket and it seems to be correctly handled by VASmalltalk.

In this method a socket option ("SOREUSEADDR") is set to true (if the configuration of the tcp network allows it, which is normally the case of VASmalltalk).

Actually I would wish, that the Seaside control panel (or its non-gui manager) should create its own (Sst) TCP transport configuration and set this option to false - perhaps even use the SOEXCLUSIVEADDRUSE option to make it more secure (but this option is not available under XP) and should use this new configuration to configure its sockets.

If you do not set this option you get the error you might expect ...

All the error checking (add another server adaptor) is done high-level oriented in VA - actually they should allow to create the server adaptors without error checking and just rely on the SstError returned by low leved methods.

Actually I was not aware, that this is handled in that way by VA - but Joachims posting forces me to look for the reasons.

And microsoft says:

"The SO_REUSEADDR socket option allows a socket to forcibly bind to a port in use by another socket."

Julián Maestri

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

As far as I know, the option to reuse a used address is not the default. You should expect an error if you try to bind and listent at an addres that it's already being used.

I had the same problem and as a workaround i had to check if the port was available before starting the server. (In my case an HTTP server and a WebService server) so 2 port checks were necessary.

To check, basically i try to bind and listen, then close, if nothing happens, the address:port was available, else, an error is signaled.

isAvailable: anAddress toBeListenedOn: aPort

    | socket result socketAddress |

    socketAddress := (SciSocketAddress family: SciSocketConstants::AFINET)
        address: anAddress inetAddr;
        port: aPort;
        yourself.

    "Create the socket"
    socket := SciSocket newStreamSocket.

    "Try to bind to the desired address"
    result := socket bind: socketAddress
    result isSciError
        ifTrue: [
            socket close.
            self error: ('Could not bind at %1 due to %2' bindWith: socketAddress printString with: result message)].

    "Try to listen at that address. 5 is the listening queue size, not important here because we are just checking"
    result := socket listen: 5.
    result isSciError
        ifTrue: [
            socket close.
            self error: ('Could not listen at %1 due to %2' bindWith: socketAddress printString with: result message)].

    socket close

jtuchel

Re: how Tor find out if port is in use?

In reply to this post by jtuchel

Hi again,

I'm coming back to this "old" problem for two reasons:

1.) A question by David on the Pharo Users Mailing List reminded me of this problem

2.) We'll soon hold 8.6.1 in our hands

and I'd be interested to know if changes were made to WASstServerAdaptor to address the issue.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.