EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Joe Reichman]

Hi,

 

 All regarding my earlier inquiry can anyone correct me if I am wrong

 

I don't think you can have multiple open connections ( in the process of
read and writes ) on the same port/same ip ??  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Edward Jaffe]

Joe Reichman wrote:

I don't think you can have multiple open connections ( in the process of
read and writes ) on the same port/same ip ??
  


The (E)JES Workstation Component TCP/IP broker listens on a single port 
and, when a connection is handled, uses give/takesocket to hand the 
socket to a subtask and goes back to the listen loop. Later, the socket 
is given to the user's EWC server address space. We have multiple TCBs 
and multiple address spaces all sharing and doing concurrent read/write 
to the same IP/port. (At least it appears to be concurrent.)


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Scott]

Well, I don't want to say "yes" outright, since I don't know what makes you
ask.  The well known ports (21, 22, 80, 443, and the color "purple") are all
just a front end.  Your TCP/IP subsystem "forks" it off to your server
application with a different port that that process listens on.  That way,
the original port (21, 22, 88, "blue 42") can remain open for new
connections to be established.  The client then requests whatever data and
the connection is closed, the child dies, and the port is released back to
the assignable pool.

I'm not a TCP/IP "engineer" or one of those liberal elite "computer
scientists" but this is the general idea.


Scott

On Tue, Oct 27, 2009 at 8:11 PM, Joe Reichman wrote:

> Hi,
>
>
>
>  All regarding my earlier inquiry can anyone correct me if I am wrong
>
>
>
> I don't think you can have multiple open connections ( in the process of
> read and writes ) on the same port/same ip ??
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Joe Reichman]

I got this error from Windows saying it couldn't create a CAsynSocket Class
for the same ip/port

Maybe if it open and closes the socket..


At work our shop is heavily XCOM based uses XCOM to submit JOBS from the PC
as we are VSE and in the process of converting to MVS (VSE HAVING not having
a built in edtitor)

 and it XCOM seems to be  single threaded only one connection on the port

But XCOM is an old VTAM application program though there TCP/IP suppourt


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Edward Jaffe
Sent: Tuesday, October 27, 2009 11:37 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: EZASMI Concurrent Server cann't handle mutiple open connections
in the same port

Joe Reichman wrote:
> I don't think you can have multiple open connections ( in the process of
> read and writes ) on the same port/same ip ??
>   

The (E)JES Workstation Component TCP/IP broker listens on a single port 
and, when a connection is handled, uses give/takesocket to hand the 
socket to a subtask and goes back to the listen loop. Later, the socket 
is given to the user's EWC server address space. We have multiple TCBs 
and multiple address spaces all sharing and doing concurrent read/write 
to the same IP/port. (At least it appears to be concurrent.)

-- 
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Joe Reichman]

thaNKX

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Scott
Sent: Wednesday, October 28, 2009 12:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: EZASMI Concurrent Server cann't handle mutiple open connections
in the same port

Well, I don't want to say "yes" outright, since I don't know what makes you
ask.  The well known ports (21, 22, 80, 443, and the color "purple") are all
just a front end.  Your TCP/IP subsystem "forks" it off to your server
application with a different port that that process listens on.  That way,
the original port (21, 22, 88, "blue 42") can remain open for new
connections to be established.  The client then requests whatever data and
the connection is closed, the child dies, and the port is released back to
the assignable pool.

I'm not a TCP/IP "engineer" or one of those liberal elite "computer
scientists" but this is the general idea.

<http://infolab.stanford.edu/CHAIMS/Code/Wrappers/TCPIP_CPAM/webpage/TCPIP.h
tml>
Scott

On Tue, Oct 27, 2009 at 8:11 PM, Joe Reichman
wrote:

> Hi,
>
>
>
>  All regarding my earlier inquiry can anyone correct me if I am wrong
>
>
>
> I don't think you can have multiple open connections ( in the process of
> read and writes ) on the same port/same ip ??
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Rob Scott]

Jon,

If you are serious about writing a concurrent server then I advise that you use 
APITYPE of "3" and the ASYNC=('ECB') option on the INITAPI. 

You then need to cover the async operations (READ/WRITE/CONNECT..etc) with a 
timer exit and a WAIT on an ECBLIST (one ECB for the timer, one for the EZASMI 
service and maybe one more for your task shutdown). 

This will cater for those (rather too often) situations when your conversation 
goes into some sort of IP "hang" when there are problems or the client (or 
client system) goes away. You also need the UEEXIT to handle your own host 
shutdown as well.

Interspaced with all this, you need a method to determine from the EZASMI 
service name and the ERRNO (one from a rather long list) if your conversation 
actually has a problem or not.  

Rob Scott
Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305 
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joe Reichman
Sent: 28 October 2009 04:45
To: IBM-MAIN@bama.ua.edu
Subject: Re: EZASMI Concurrent Server cann't handle mutiple open connections in 
the same port

thaNKX

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Scott
Sent: Wednesday, October 28, 2009 12:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: EZASMI Concurrent Server cann't handle mutiple open connections in 
the same port

Well, I don't want to say "yes" outright, since I don't know what makes you 
ask.  The well known ports (21, 22, 80, 443, and the color "purple") are all 
just a front end.  Your TCP/IP subsystem "forks" it off to your server 
application with a different port that that process listens on.  That way, the 
original port (21, 22, 88, "blue 42") can remain open for new connections to be 
established.  The client then requests whatever data and the connection is 
closed, the child dies, and the port is released back to the assignable pool.

I'm not a TCP/IP "engineer" or one of those liberal elite "computer scientists" 
but this is the general idea.

<http://infolab.stanford.edu/CHAIMS/Code/Wrappers/TCPIP_CPAM/webpage/TCPIP.h
tml>
Scott

On Tue, Oct 27, 2009 at 8:11 PM, Joe Reichman
wrote:

> Hi,
>
>
>
>  All regarding my earlier inquiry can anyone correct me if I am wrong
>
>
>
> I don't think you can have multiple open connections ( in the process 
> of read and writes ) on the same port/same ip ??
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Joe Reichman
Sent: Tuesday, October 27, 2009 10:12 PM
To: IBM-MAIN@bama.ua.edu
Subject: EZASMI Concurrent Server cann't handle mutiple open connections
in the same port

Hi,

 

 All regarding my earlier inquiry can anyone correct me if I am wrong

 

I don't think you can have multiple open connections ( in the process of
read and writes ) on the same port/same ip ??  


Well, kinda. As you get a connection, you do a givesocket and a
takesocket (from the "butler" TCB/Thread to the "handler" TCB/Thread).
This somehow becomes an ethereal port to that handler (which means that
you are sending using a different port number while the other end
continues with what it knows).

This means, in your system, that the connection follows that socket to
the issuer of takesocket.

And if this is confusing, I understand. I've been trying to get my hands
around all of this as I get to modify some of this from time to time
(ISV with a product that uses it).

Regards,
Steve Thompson

-- Opinions expressed by this poster may not be those of poster's
employer --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Eric Chevalier]

On 27 Oct 2009 20:12:50 -0700,
joereich...@optonline.net (Joe Reichman) wrote:

>I don't think you can have multiple open connections ( in the process of
>read and writes ) on the same port/same ip ??  

Echoing Scott, I hesitate getting on my soapbox since I don't know
what makes you ask. But in general, the answer is "yes"; that's how
most TCP/IP server processes work. Disclaimer: I have no experience
with socket programming on the mainframe; all of my network experience
has been on alternate platforms.

First, keep in mind that "reads and writes" implies stream types of
connections such as TCP, rather than datagrams (UDP and so forth).
Streams have the property of a local socket (IP address and port) AND
a remote IP address and port. That combination makes each stream
connection unique.

In the *nix world, typical server logic (greatly simplified) would
look something like:

int s = socket();
bind(s,...);
listen(s,...);
do
{
int fh = accept(s,...)
fork();
}
until (finished);

The listen() function waits for client connects. As these connections
arrive, accept() process a connection and returns a file handle[1].
That handle then gets passed to the child process created by fork().
Although any number of child processes could exist, and each child
process has a unique file handle for its client connection, all of the
children are reading and writing via the same local port which was
defined by the initial call to bind(). The fact that each read/write
operation is performed on a file handle with a unique REMOTE IP/port
allows the TCP/IP stack to use the same local IP/port for all of these
connections.

If there's any doubt about this mechanism, here's an extract from a
"netstat conn" command on our mainframe. Note that we have 8 active
tn3270 client connects, all with the same local socket port:

TN3270   0037 Listen
  Local Socket:   ::..23
  Foreign Socket: ::..0
TN3270   00047D9F Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.64.41..1425
TN3270   00045ED3 Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.85..3041
TN3270   5CBE Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.60..1077
TN3270   00045EEE Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.85..3042
TN3270   000464D6 Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.98..1040
TN3270   00044D18 Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.76..1068
TN3270   0003702B Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.60..1263
TN3270   000415ED Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.60..1677
TN3270   00045EAD Establsh
  Local Socket:   :::192.168.10.193..23
  Foreign Socket: :::192.168.10.85..3040

Of course, if two remote clients on the same host managed to establish
connections to the server using the same client port, the server would
not be able to distinguish those connections. (However, the second
client attempt to establish an outbound connection to the server would
likely get a "socket already in use" type of error.)


On 27 Oct 2009 21:18:42 -0700, sc...@aitrus.org (Scott) wrote:

>The well known ports (21, 22, 80, 443, and the color "purple") 
>are all just a front end.

That may be true, but doesn't have to be. In the *nix world, the
"super server" inetd/xinetd is often used to perform the process of
listening on a socket on behalf of a server process like ftp, telnet,
etc. (The mainframe TCP/IP stack (I believe) can perform that same
function.) There are advantages to this approach, since it can allow a
single process to perform a consistent approach to security, logging
and so forth. But a server process could easily bypass the super
server and perform its own bind/listen/accept process. I've
encountered server processes that can be configured either way.

>Your TCP/IP subsystem "forks" it off to your server application 
>with a different port that that process listens on.  That way, 
>the original port (21, 22, 88, "blue 42") can remain open for 
>new connections to be established.  The client then requests 
>whatever data and the connection is closed, the child dies, and 
>the port is released back to the assignable pool.

I think that's close, but the "fork" process does not create a
separate port; see the netstat example above. Again, that's possible
because each forked process is communicating with a unique remote
socket, allowing the local ends of all these connections to share the
same local port.

I won't argue that this narrative is Absolute Truth, but I'd
definitely argue it over a beer or two! :-)

Eric

[1] An extract from the

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Joe Reichman]

When I had a different port on windows/Client side MVS wouldn't accept  
the connection


Sent from my iPhone

On Oct 28, 2009, at 11:29 AM, Eric Chevalier   
wrote:



same


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Henry Willard]

Joe Reichman wrote:

> Hi,
>
>
>
>  All regarding my earlier inquiry can anyone correct me if I am wrong
>
>
>
> I don't think you can have multiple open connections ( in the process of
> read and writes ) on the same port/same ip ??
>

Typically all connections on the server or listening side are to the same
port and IP address. Each connection has its own socket which is created by
accept or equivalent. A connection is defined by the IP/port addresses of
both endpoints. An attempt to bind a socket to a port that is in use by
another connection will fail.

Having used both the EZA and BPX socket interfaces, I much prefer the
latter. The BPX interface is not only easier to use, but more powerful. Plus
I believe these days the EZA code uses the BPX interface. If your server is
running authorized, you can use most of the BPX socket interfaces in SRB
mode.

Regards,
Henry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Shmuel Metz (Seymour J.)]

In <000801ca5785$9f8e9930$deabcb...@net>, on 10/28/2009
   at 12:17 AM, Joe Reichman  said:

>I got this error from Windows saying it couldn't create a CAsynSocket
>Class for the same ip/port

A TCP connection is identified by the source-IP:port and the
destination-IP:port. If you need multiple concurrent connections to the
same IP:port then you must create multiple source IP:port sockets.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EZASMI Concurrent Server cann't handle mutiple open connections in the same port

[Shmuel Metz (Seymour J.)]

In <71mge5d7ruvg5q72l2nadi98768iten...@4ax.com>, on 10/28/2009
   at 10:29 AM, Eric Chevalier  said:

>First, keep in mind that "reads and writes" implies stream types of
>connections such as TCP, rather than datagrams (UDP and so forth).
>Streams have the property of a local socket (IP address and port) AND a
>remote IP address and port. That combination makes each stream connection
>unique.

That's true for TCP, but not for, e.g., SCTP. BTW, does CS in z/OS support
SCTP?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html