EMSRV client port specification

[steven.lafavor]

Got a question about connecting to EMSRV....

I know that the EMSRV process listens on port 4800 by default, and that the port can be changed by using the -P#### parameter. I also know that if you change the default, you need to specify the port in the abt.ini ServerName parameter. But what about the port opened on the CLIENT (i.e. the Smalltalk image) that connects to the 4800 port?

Due to architectural considerations at my company, our test machine is in a different architectural layer than our code repository, and we have been granted authorization that we can open a port from the client to the server. Can we just pick any port? And if so, how would one specify for the client to use that port? Or is this all just a non-issue (i.e. if a port is opened to the server, it will automatically be used)....

For example, my current connection to the repository is using port 4698 locally to connect to port 4800 on the development server......

As you can see, architectural networking is not my strong suit

*Steve*

[Diane Engles]

Could you clarify what you mean by architectural layer -- a network subnet perhaps? And what specific kind of authorization?

I am no network expert either, but I suspect the authorization has been granted based on basis of the IP address of the client request ( a specified range of IP's may have been granted authorization) , or possibly authorization has been granted for the server to listen and accept client connections on a specific port.

If either of these is the case, the client port is a non-issue. In general client ports are assigned dynamically (using the lower range of the "registered ports", 1024 to 49151) by the TCP layer. So an application in general doesn't specify a client port.

[TheIconoclast]

Steve,

Again, not a network expert, but I have had considerable dealings with various firewalls for the applications I work with. In every case, it's always been a matter of having the firewall "port exception" set for the destination, not the source. Consider the following:

Client (say, 192.168.0.1)
-------Firewall A--------
...A Series of Tubes...
-------Firewall B--------
Server (say, 10.0.0.1, with a server app on port 65535)

I'd need to get an exception on Firewall A to allow 192.168.0.1 outbound to 10.0.0.1:65535, and an exception on Firewall B to allow 192.168.0.1 inbound to 10.0.0.1:65535. This lets my app, on whatever dynamic port it selects, to establish a connection to the server's port 65535. Once that connection is established, traffic is allowed to flow back and forth between the two. (That's surely an oversimplification, but it's probably enough detail for a high-level understanding of what is going on.)

Hope that's at least a bit enlightening!
Brian

[steven.lafavor]

Just as a followup.....

The tech person that asked me the question was not sure why he was getting the information, and it turns out that there was a snafu in the instructions. It turns out that opening the SERVER port is all that was necessary. Thanks to all for your help!

*Steve*