Re: [tor-dev] [Stegotorus] Fundamental problem with ack/retransmission mechanism

[vmonmoonshine@xxxxxxxxx]

Hey Zack,

Thanks for replying so fast.

Zack Weinberg <zackw@xxxxxxxxx> writes:
>and the retransmit of packet 1 ought to be happening on a
>*different* connection, if we have one.  (Which steg are you using?)
I'm using nosteg steg. I thought if something is going to work, better, it
works with the simplest steg. nosteg only open one connection and pass
everything through it as long as there is no reason to drop it, for bad
header etc.

> So I'm not understanding exactly what the "dropper proxy" does.  Does
> it prevent TCP from providing reliable delivery?  If so, how?
It sits at socket_read_cb and sometimes doesn't copy what libevent's has
read from one side of communication, into the buffer of the other
side. So, what you say, means that libevents socket_read_cb calls are more
refined than an entire TCP packet that TCP guaranteed to deliver. I.e,
libevent break something that TCP guaranteed to deliver in smaller
parts. 

If this is true, I guess because TCP is giving us a stream there is no
way for us to know where to drop to have a legitimate simulation of real
life packet drop in that stream, unless I incorporate part of chop in
the dropper proxy to read their headers and detect end of packet.

> ST absolutely *does* need a congestion
> control mechanism, though, to prevent the entire circuit from getting
> killed because it overran the fixed-size reassembly queue, and as long
> as we have to do that ...
>
Then maybe I just start an axe timer whenever when I want to send and
the transmit queue is full and delete the timer whenever the queue
moves.

Cheers,
Vmon
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev