× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Uh, Jim, I think port 2623 is the port on the client side.  Client program
asked to open a port TO host.com:80.  The client OS decided to use port
2623. When the server accepted the connection, it remembers that this socket
has to reply to 63.220.237.194 port 2623.  That's what you're seeing on the
server: the client address and port that it's talking to.  The client is
socket is still pointing to host.com port 80.  No handoff.

Eric DeLong
Sally Beauty Company
MIS-Sr. Programmer/Analyst
940-898-7863 or ext. 1863



-----Original Message-----
From: Jim Langston [mailto:jlangston@celsinc.com]
Sent: Tuesday, April 23, 2002 2:39 PM
To: 'rpg400-l@midrange.com'
Subject: RE: Sockets problem (what is)


In windows do a DOS window and type NETSTAT -an

This is best done from a HTTP server to show what is going on.

For each connection you will see the IP of the local server and port, and
the remote client and port.  The server will see it on port :80, but the
client will be on some obscure port.  Here is an example from our own IIS
server:

  TCP    192.0.0.8:80           63.220.237.194:2623    ESTABLISHED
  TCP    192.0.0.8:80           63.220.237.194:2624    ESTABLISHED
  TCP    192.0.0.8:80           64.242.2.37:29903      ESTABLISHED
  TCP    192.0.0.8:80           64.242.2.37:29908      ESTABLISHED
  TCP    192.0.0.8:80           65.29.109.59:1266      ESTABLISHED
  TCP    192.0.0.8:80           66.76.46.228:2166      ESTABLISHED

for like 63.220.237.194 it has moved the request from port 80 to port 2623
internal to the server, but the remote computer's client still sees it as
port 80.  This is HTTP port 80 instead of Telnet port 23, but same
difference.

Regards,

Jim Langston

-----Original Message-----
From: Scott Klement [mailto:klemscot@klements.com]

On Mon, 22 Apr 2002, Jim Langston wrote:
>
> The server will have a listener on some port.  In this case telnet port
23.
> A client requests a connection to the server on port 23.  The server
> receives the request and hands the port off to a new thread (usually)
which
> establishes the connection on some other port.

This is not true.   A telnet server does not switch you to another port.
Maybe you're getting "socket" and "port" mixed up?  At any rate, there's
only one port for a telnet server -- 23 -- and it does not change after
you connect.

> As far as the client is
> concerned you are connected on the server on port 23, although in the
server
> it may see it is port 5123.

No.  The server sees it as port 23.   Maybe you're thinking of the
client's port?   The server's port remains 23.   The client's port was
most likely picked by the OS from the range of unused port numbers, and
given the first one that's available.   Usually, people don't worry about
the client's port, since the client doesn't need to listen for
connections, and you don't need to connect to a client -- since it's the
one that does the connecting.

But, this might be where you're confused.   The client side could be 5123
and the server side 23...  At any rate, they don't change.  Once they're
connected, those numbers are fixed until the connection is closed.

> The client doesn't know, or care, what the real
> port is on the server.  That port switching is all server side and the
> client doesn't see it or even know if it's happening.

No.  Normally there is no port switching.   If there is an unusual
circumstance where port switching needs to occur, then the client
definitely needs to know about it, since it will have to call connect()
again to the new port.




_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.