Will Trillich wrote:
On Sat, Jun 26 at 08:33PM +0800, John Summerfield wrote:
I'll stick with "by definition." ftp in active does things a little oddly: when the client requests a transfer, it sends the port command: I don't know the full details,but some of the information it provides is the IP address and port for ftpd to connect to to send the data. So far as the protocol is concerned, the server makes a client connexion request to the client program which in consequence becomes a server.I don't understand why the server would be making theit's not "by definition" -- it's "in the VAST majority of cases".
connexion request. By definition, the client does that.
as in "very seldom, and it's surely suspicious behavior that
should be investigated by at least three government agencies at
the highest level, there will be a case for forwarding server
ports to the client, not that there's anything wrong with that."
aha. i see your perspective -- you're calling quickmate a
server, even tho it's on the user's client-side machine. by that
arrangement, yes, it's the server.
That's standard terminology.
Also, some server software (sendmail is an example) makes a client request to a connecting host to discover the identity of its client. The server is identd (service auth).
It is. As I alreadt explained, it's talking to a proxy server (ssh) on your machine. How the server satisfied the request is irrelevant.but the tunnel is initiated locally, so we forward a remote port to the local machine in order to accomplish our task. :)
aha! but, as you said:
> You don't want loopback devices. The loopback device is > for me to send messages to myself: the client and server > are on the same box.
"i'm talking to myself"! 127.0.0.1 is the loopback interface,
so you "don't want that"... :) unless you've got the port
forwarded elsewhere. right? yes? hmm?
My web browser is talking to a server on my loopback device, yes. What the server does is respond validly to HTTP requests. Whether it gets the date from local store (Apache with static html) or generates it (Apache with CGI or PHP and a database backend) or entirely from across a network (as Squid does) is irrelevant.
I'm not routing traffic from the loopback device, and that's
what you were talking about.
ssh -L80:192.168.0.1:80 distant.server.there lynx localhost:80
lynx thinks it's talking to its own selfsame machine, tho the
request gets beamed to 192.168.0.1 instead.
ssh -R10001:127.0.0.1:10001 distant.server.there quickmate localhost:10001 &
quickmate thinks it's listening to locally-originating
connections, but it's gonna be getting them from the remote
end of the tunnel instead.
No, it's getting it from a client on _its_ local host. Whether the client is sshd (as in this case) or the client program in your hands is irrelevant.
So far as you're concerned, the server is on your peecee.
OTOH quickmate sees its client as being on the same hardware it's running on.
same thing, different direction.
THAT's what i'm talking about.
Best you become accustomed to standard terminology. The "Using C on the UNIX System" book has sample code to illustrate my point.
Did you check the book? There are other documents you could check: I once had documents on client/server programming in REXX (and did some), and Perl has heaps of support for it.
You don't want loopback devices. The loopback device is for
me to send messages to myself: the client and server are on
the same box.
they APPEAR to be on the same box, thanks to the magic of port-forwarding tunnels. whether it's -R (coming) or -L (going) it's magic, either way.
Clients do not listen and clients do not accept questions. That has caused most of our confusion.
A TCP client uses socket() and connect(). A TCP server uses socket(), bind(), listen() and accept().
See using C on the Unix system, O'Reilly & Assoc.
conceptually quickmate fills the definition of a client -- it gives the user a menu to work with to converse with the remote database server; operationally, it's serving requests to port 10001 like a server would.
and to get it to work we use a remote-to-local tunnel. works like a dream!
See this illustration: [EMAIL PROTECTED]:~$ ssh -L2022:127.0.0.1:22 192.168.1.121 Linux Echidna 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown No mail. Last login: Tue Jun 29 21:50:05 2004 from 192.168.9.114 [EMAIL PROTECTED]:~$
and then [EMAIL PROTECTED]:~$ ssh -p 2022 127.0.0.1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
<snip> Linux Echidna 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown No mail. Last login: Wed Jun 30 08:00:52 2004 from 192.168.9.114 [EMAIL PROTECTED]:~$ w 08:01:25 up 6 days, 20:28, 3 users, load average: 0.04, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/18 localhost 23Jun04 42:35m 0.14s 0.14s -bash summer pts/20 192.168.9.114 08:00 33.00s 0.05s 0.05s -bash summer pts/24 localhost 08:01 0.00s 0.08s 0.05s w [EMAIL PROTECTED]:~$
The connexion from 192.168.9.114 is the first above. summer's connexion from localhost is the second. the "From" column is the client end, and quickmate sees it in exactly the same way.
--
Cheers John
-- spambait [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
