Newsgroup: it.comp.reti.ip-admin
Titolo: FXP

Che cos'e' l'FXP? Mi hanno detto che e' una specie di FTP ma vorrei
capirne di piu'
-- 
Sono gradite risposte anche via e-mail.
Grazie e ciao,
Giglio
E-mail: 
gig...@poboxes.com
Homepage: 
http://fly.to/giglio/
ICQ: 12385960

 capirne di piu'
L'ho scoperto 10 minuti fa.. ;)
E' l'ftp contemporaneo su più hosts. Permette anche di copiare da un Hosts
all'altro SENZA passaggio intermedio. 8)
-- 
			Luca Amicone
			ICQ: 14890779 FUORI USO !!!
--
	Tutti sono necessari, nessuno è utile.
		-- M. Marchesi

 all'altro SENZA passaggio intermedio. 8)
Ti puoi spigare meglio? Magari via email...


 Ti puoi spigare meglio? Magari via email...
E' un trucco che uso da anni in "raw telnet" sul server FTP,
purtroppo non funziona quasi mai perche' la maggioranza dei
server FTP non accettano piu' (per ovvi motivi di sicurezza)
di aprire il socket "dati" su un IP diverso dal socket 
"controllo", ne tantomeno da un numero di porta riservato.
In dettaglio funziona cosi':
Ti connetti a due server FTP
Metti uno dei due in "passive mode"
Inizi il trasferimento con "send" su uno e "receive" sull'altro
Dai a quello in active mode i numeri di IP e porta che ti ha
dato quello in passive mode.
In pratica "cortocircuiti" il canale dati di un server con quello
dell'altro, util se sei connesso da modem e senza aprire una shell
vuoi scaricare 200 mega di roba da qualche parte a un tuo server
senza aprire una shell e senza farli "passare" dal modem...
Mi pare di capire dal post che ora hanno messo in giro una
utlity che fa il tutto automaticamente, buona cosa, dubito solo
che funzioni spesso...
Per quanto riguarda il discorso di "ftp contemporaneo" e' molto
piu' vecchio e diffuso e legata al solito discorso dell'inefficienza
del protocollo TCP (che e' troppo "prudente" nell'occupare la banda).
Quello lo puoi fare con quasi tutti i client FTP, al massimo aprendo
piu' copie del client: lanci il download di diversi file in parallelo,
anche se sono tutti sullo stesso server e anche se ognuno di essi va
piu' lento che se fosse da solo il transfer rate complessivo e' migliore,
questo almeno fino a 3-5 file transfer in parallelo, andando oltre
ridiventa piu' lento. I dettagli tecnici del perche' sono semplicemente
troppo complessi (siamo sull'ordine di grandezza delle sei pagine
di formule e sistemi di equazioni...).
Ciao,
-- 
Andrea

 di formule e sistemi di equazioni...).
E spiegabile in poche parole?


 che funzioni spesso...
L'ho vista qui:
http://nonags.ids.it/main.html
nella sezione FTP Client (Freeware)
-- 
			Luca Amicone
			ICQ: 14890779 FUORI USO !!!
--
	Questo è un paese libero
	... nessuno vi obbliga a rimanere.
		-- Kipli

 nella sezione FTP Client (Freeware)
Grazie!


 
       Date: Fri, 23 May 1997 18:01:46 +0200 
Well i'll try to explain my point as briefly and as clearly as I can,
I assume of course that you already know exactly how TCP works and how
is implemented and how currently IRC uses it for server-server links.
I didn't study these matters at school, i'm not a mathematic guy or
so... therefore I might be wrong somewhere, if so let me know.
Bye now know that what follows had, since now, proof of evidence in
many on-field tests I've personally done.
Let's see it in numbers, definitions and example values; of course packet
sizes, times, loss and so on are to be considered "average":
I have a TCP stream and (make it simple) I am porting
data from "A" to "B".
I'll call the packet loss factor PL, beeing it 5% is gonna be
PL = 0.05 (dimensionless, it's a factor)
Similarly we'll have an average round loop ping time that
i'll call LPT, to be expressed in seconds
B has an "input TCP window", let's name it IB, this gonna have
a maximum, IB is defined and adjusted dynamically by the kernel but
anyway with a maximum limit) of maxIB. This maxIB is _hardcoded_
in the TCP protocol itself cince the space left for it in a
TCP PDU is 16 bits it is 64 Kbytes... no more. Let's say that
our TCP implementation does it at its best and thus uses
IB = maxIB = 64 Kbytes.
If A's implementation of TCP is smart enough it will try to adjust the
"expire time" (ET) of the packets (the time it waits to have a packet
ACKed before resending it) to some that lets about 90-95% percentile
packets get through without beeing resent, this will be somewhere
between the average and the maximum ping loop-time.
Actually TCP needs to set ET greater than LPT of a significative
amount in order to keep that "security area" to avoid that a big
number of packets start beeing considered lost when they have
just been delayed some milliseconds, I'm not that much in statistic
but I'm pretty sure that it will be confirmed something like
ET > 1.5 x LPT
that is "TCP will wait at least one time and half the average
ping-loop time for the ACK before considering a packet lost"
A study over the gausssian distribution of propagation delays
in a typical network and a definition of the maximum percentile
of packets that we are ready to resend even if they were not
really "lost" should confirm this.
Finally let's say that the packet size will be 1k (1024 bytes), this
is realistic too if you consider how IRC uses TCP. (packets size,
PS = 1 Kbyte) and as we will see will not affect much more than it
my considerations.
If there was no packet loss and the round loop was always under that
350 ms (ET), so no packets ever resent  "A" (knowing the receive window
of B, that is 64 K) will be able to "send forward" 63 packets after
"packet X" before having packet "X" ACKed. It cannot send packet
X+64 before the ACK for X comes back (it would be out of the receive window)
but ACK(X) cannot come back before our ping-loop time, thus before
<the moment coming LPT seconds after packet "X" has been sent>.
Result: between the moment when byte X has been sent and the moment
when byte X+IB can be sent there will be (at best) a delay
of LPT seconds. This implies that we have a MTT (maximum theorical
througput) of  IB/LPT
Thus:
MTT = IB/LPT  [byte/sec = byte / sec, dimensionally ok]
This "limit" has nothing to do with bandwith, it's a limit imposed
by the ACK method, it's related to the fact that in a certain
amount of time (LPT) we cannot get ACKed (note we could transmit
but we cannot get ACKed) more than IB bytes.
Statement: A TCP connection CAN NOT carry more than 64 kbytes in
round-loop-ping-time seconds, even with unlimited bandwith and
zero packet loss; this means 256 Kbytes/second on a 250ms ping
link. This is 1/18th of a T3.
The proble might seem to be only the IB size, but TCP hasn't
been designed by fools and if they did choose a 64 Kbytes value
there is a reason. (It wouldn't have costed that much to use
32 bits for that field in the datagram instead of 16).
Apparently if we can increase IB we will be able to carry much more
data: for the above statements we would set IB = 10 Mbytes so that
MTT = IB / LPT would be as large as we like. Let off the
problems that any machine would have to allocate such a buffer
for a _single_ fd...
But let's see what happens when IB grows but we have some packet
loss:
Every time a packet of data from A -> to B gets lost TCP will
require A to start resending everything it has sent toward B
_after_ that  packet (remember I just get an "ACK up to", never
a "NACK this").
Moreover the data flow from A to be will somehow "hang" for a while
each time this happens.
Infact (not existing a NACK in TCP) when a  packet "X" gets lost:
- A sends the packet X and keeps sending the following data
  while it fits in the receive window [1]
- B does not receive the packet and so doesn't not send the ACK [2]
- A will wait ET seconds and then start again sending the packet and
  everything that was after it. [3]
- B will hopefully get the packet this time and immediately ACK
  whatever it had already received in its buffer (or at least up
  to the next missing packet). [4]
- When A receives the ACK (supposed it was just one packet lost
  and therefore the whole receive window IB gets ACKed) it can step
  forward again and begin sending data at packet number "X"+(IB/PS) [5]
Meanwhile machine A has sent "useless" and "duplicated" data for
a while, exactly for LPT seconds (from [3] to [5]).
If our throughput is AT bytes/second we send AT/PS packets per second
and if PL of them are lost we have the above [1]-[5] happen (AT/PS) x PL
times per second and each time this happens we resend an average of
AT x LPT bytes, thus the bytes resent per second are:
((AT/PS) x PL) x (AT x LPT), in the above example this would become
(if we could have AT = MTT, that was 256 Kbytes second)
((256[Kb/s] / 1[Kb]) x 0.05[]) x (256[Kb/s] x 0.25[s])
[in square the dimensions] = 819.2 Kbytes/second of resent data !
of these 820K only 12K were "lost packets" the rest is caused by
the protocol.
This is a big bandwith waste but, again, we supposed in example to
have unlimited bandwith, so we don't care (Don't we ???).
Actually TCP _does_ care about it, and infact wouldn't ever let
us send through  a link like the one described data at that
rate and thus have such great packet resends ....
how does it limit us ? for first limiting our IB !
However nother "little" problem arises, we had seen that our MTT was
due mainly to the time the ACK needs to come back.... but in the
example of the lost packet the total time spent since
the packet had been sent for the first time to the final ACK has
been greater, infact has been from [1] to [5] at least equal
to ET + LPT while we expected (since we get ACKed up to byte X+IB)
it to be = 2 x LPT to mantain our MTT throughput.
There is a (ET-LPT) difference that sounds logical, basically is
the time expired from the moment when A "should have got" the ACK
and when it times out and A considers the packet "lost", nothing
we can do about it, it's a security area we need to avoid even
bigger packet loss.
This affects badly the actual throughput (AT) that we will get.
By now let's define LF (loss event frequency) to that (AT/PS) x PL:
LF = (AT/PS) x PL [dimensionally 1/sec = ((byte/sec / byte) x 1)]
or simply
LF = PL x AT / PS
How much does this affect our throughput ? Well it happens (again)
LF times per second and reduces our MTT by subtraction
Every time this happens is as if the throughput for (ET-LPT)
time had become zero.... let's evaluate this:
Over a time TT we will have an MTT throughput except that for
LF x TT times in this period  there will be an "hole" of
(ET-LPT) seconds in wich the throughput becomes temporarily ZERO
The the Average Data (AD) sent in this TT time will then be
equal to the data sent in TT less the data we would have sent
in these "holes".
Since the "holes" happen LF times per second they will be LFxTT
in our period of TT seconds.
Of course since each hole has a duration of (ET-LPT) seconds and
we loose the chance to send data at MTT rate for that duration
it results that in each hole the data that we couldn't send
is MTT x (ET-LPT)
So the total data that we couldn't send in TT will be
DL = MTT x TT x LF x (ET-LPT)
This leads to a reduction of the Actual sent data, name it AD,
that will no more be equal to MTT x TT but will be
AD = MTT x TT - DL
   = MTT x TT - MTT x TT x LF x (ET-LPT)
But sending an average data amount (AD) in a TT time means having
and average througput (AT bytes/second) of
AT = AD / TT
   = ( MTT x TT - MTT x TT x LF x (ET-LPT)) / TT
   = MTT - MTT x LF x (ET-LPT)
Just a check for dimensional consistence...
[byte/sec = byte/sec - byte/sec x 1/sec x (sec - sec)]
Let's replace some variable with the above-defined equivalents:
replacing in the last equation LF = (PL x AT / PS) we get:
AT = MTT - MTT x (PL x AT / PS) x (ET - LPT)
[byte/sec = byte/sec - byte/sec x (1 x byte/sec / byte) x (sec - sec)
          = byte/sec - byte/sec x (1/sec) x sec = byte/sec - byte/sec]
and replacing MTT=IB/LPT now:
AT = ( IB / LPT ) - ( IB / LPT ) x (PL x AT / PS) x (ET - LPT)
   = ( IB / LPT ) - ( ( ET - LPT ) x IB x PL x AT ) / ( LPT x PS )
   = ( IB / LPT ) - AT x ((ET - LPT) x IB x PL / (LPT x PS))
and thus
AT x ( 1 + ((ET - LPT) x IB x PL / (LPT x PS)) ) = ( IB / LPT )
so
AT = (IB / LPT) / ( 1 + ((ET - LPT) x IB x PL / (LPT x PS)) )
   = IB / ( LPT x ( 1 + ((ET - LPT) x IB x PL / (LPT x PS)) ) )
   = IB / ( LPT + LPT x ((ET - LPT) x IB x PL / (LPT x PS)))
   = IB / ( LPT + ( LPT x (ET - LPT) x IB x PL / (LPT x PS)))
   = IB / ( LPT + ( (ET - LPT) x IB x PL / PS ))
   = 1 / ( LPT / IB + (ET - LPT) x PL / PS )
   = 1 / (( LPT x PS + (ET - LPT) x PL x IB ) / (PS x IB) )
   = PS x IB / ( LPT x PS + (ET - LPT) x PL x IB )
   = PS / ( LPT x PS / IB + (ET - LPT) x PL )
   = 1 / ((ET - LPT) x PL / PS + LPT / IB )
ANother dimensional check:
[byte/sec = 1 / ((sec-sec) x 1 / byte + sec / byte )
          = 1 / ( sec/byte + sec/byte) = 1/(sec/byte) = byte/sec ]
This if we imagine to use an "infinite lenght" Input Buffer (IB = +inf)
will lead us to LPT/IB = 0 (and how we have seen MTT = +inf) so
the equation reduces as:
AT = 1 / ((ET - LPT) x PL / PS )
   = PS / ( PL x (ET - LPT) )
   = (PS/PL)/(ET-LPT)
[Again: byte/sec = (byte x 1) / (sec - sec)  = byte/sec ]
In the last one if we are tring to optimize TCP we have
LPT and PL constant (no way to affect them) PS basically
locked (if we use bigger packets than the ones of our
physical layer they'll be fragmented and the chanche
of having at least one fragment of the packet lost grows linearly,
thus PS/PL ends up beeing constant too and undependent on PL once
PL is significatively > than the physical packet.
ET also cannot be closer to LPT more than that, because
it would increase badly PL (the less room we give to
gaussian distribution of ACKs around the average pingtime
the more packet we consider lost wrongly]
How great is this new limit ?
Let's see: pingtime with 1024 bytes average 250 ms, ET safely
set at 350 ms, packet loss 5% ... what comes out ?
AT = (1024/0.05) / (0.35-0.25) = 20480 / 0.1 = 204800 bytes/sec.
that is exactly 200K/second
But this would mean having an infinite lenght buffer wich,
by definition, is impossible, in pratical matter the bandwidth
we can get with such ping/loss is a LOT smaller.
Anyway let's take for good the following results (and please place
them in the FAQ as soon as we will have one, under the topic
"Why TCP's strict sequencing places serious limits to the
throughput of the connection ?")
======== SUMMARY OF RESULTS =========
Given a conncetion bewteen two machines in wich:
PS : Is the size of PDU packets that end up beeing used by TCP
     at full burst load (wich is usually equal to the underlying
     physical layer packet size, if TCP is implemented well)
     In bytes.
PL : Is the packet loss between the two machines (using packets
     os size PS) expressed as factor, example 5% -> PL = 0.05
LPT: Is the average loop ping time between the two machines,
     in seconds, example avg/ping = 200ms => LPT = 0.2
ES : Is the expire time of data sent and not yet ACKed after wich
     TCP will consider that data lost, usually something like
     ES = 1.5 x LPT
IB : Is the Input window buffer size wich by definition cannot
     be greater than 64 kbytes (due to the fact that in the
     TCP PDU there is a 16 bits field to store it's size in bytes).
     In bytes.
Regardless of how much band is available and letting out any other
consideration the maximum teorical througput of a _single_ TCP
connection between the two machines cannot be more than
MTT = IB/LPT
Moreover, even if the Input Buffer Size (IB) could be increased
the maximum actual bandwith of a single TCP connection between
the two machines cannot theorically be greater than:
AT = (PS/PL)/(ET-LPT)
Reagrds, Andrea aka Nemesi.
       Prev by Date: TCP vs UDP (was Re: Mesh linked net ?) 
       Next by Date: Of routing.. 
       Prev by thread: Suggestion (was Re: Summary so far.) 
       Next by thread: Of routing.. 
       Index(es): 
              Date 
              Thread
-- 
Andrea

capirne di piu'
Beh ci sono vari client fxp per Il mondo Windows
PEro' non mi e' mai stato chiaro
come bisogna settare un ftp server
per fare in modo che sia possibile utilizzarlo il fxp!
Qualcuno lo sa?


wrote:
:E' un trucco che uso da anni in "raw telnet" sul server FTP,
[...]
e' possibile fare la stessa cosa con la posta? non tanto con l'SMTP ma con
il POP
su quale porta? protocollo?
THX
Oha

su quale porta? protocollo?
110/tcp
-----------------------------------------------------------------------------
   Andrea Mansella  Referente AGI sez. Rimini  
http://www.amyresource.it/AGI
   E-Mail: 
aman...@rebel.net
        FidoNet: 2:332/301.1
-----------------------------------------------------------------------------