[tor-dev] [GSoC] [Stegotorus] Recent activities

[vmon]

Hey Zack,

I know you are super busy packing for your big move, but I thought as tomorrow is the hard deadline for GSoC, is not a bad ideas to give you some final update.

So most of last week I spent on the conflict that occurred between
libcurl and libevent having their eyes on the same socket. I tried
different ugly and uglier solutions but finally settled on this one
which is not that bad:

http://stackoverflow.com/questions/12021217/how-to-ask-libcurl-not-to-listen-on-a-socket-just-send-a-url-request-over-it?answertab=votes#tab-top

After that, I'm passing all time line tests now. However, when I look at
the client log, I see that some of the sequence no are missing in the
recv: like this

203.7169 [debug] recv: <3.81> receiving block 42 <d=0 p=9 f=DAT>
T:203.7170: ckt 3 <ntp 1 outq 0>: recv 42 <d=0 p=9 f=DAT>

and the next recv is like this:

203.7926 [debug] recv: <3.99> receiving block 60 <d=0 p=1 f=DAT>
T:203.7927: ckt 3 <ntp 1 outq 0>: recv 60 <d=0 p=1 f=DAT>

Is this for sure an error and loss of data? or there is a normal
situation that such a thing can happen? For example when the whole
block can't be sent over one connection? (otherwise how do the tl tests all pass?).

Further more, I merged the payload scraper and stegotorus. I this way,
http_apache checks for the payload database and if it's not there it
calls the scraper (it needs apache to be installed on the same
machine). These all are commited on the github.

I started writing a unit test that fetch a webpage directly (using curl)
and through stegotorus and check if they are the same. I thought curl is
best approximation of a browser that is available to us. But as I don't
think I can finish that till tomorrow, I'm going to spend the remaining
time on documenting the 'uri transport protocol' and deal with small
issues.

After we are done with the evaluation, I'll go back to unit testing.

Thanks for your help.

Cheers,
vmon