Trust

As a quick recap:

1. Authentication i.e. verifying that someone has the proper credentials to enter the system can be done via 
1. Passwords
2. Public key encryption. The gatekeeper will request from the person some agreed upon message that will be encrypted with the private key, and only the public key can decrypt it. This way, the gatekeeper knows that the person has passed the truth-test for the public-key/private-key mapping. Should the gatekeeper "trust" this person ? This is a separate issue and this is handled via "Certificates"

Imagine the following scenario. You meet someone new and they need proof that you have the credentials you claim you do. You can say orally that you have a M.S. Degree. Is that good enough ? How can they "trust" you ? To make them trust you, you will present them with some certificate signed by someone THEY trust. e.g. you can show the university certificate. They can then call up the university and find out if you have indeed passed. In PKI, the certificate presented will help the new party to verify that. However, do they "trust" the university ? This is another separate question. In case of Digital Certificates, the following logic applies.

1. The CA has confirmed that the public-key that shows up in the certificate is "trustworthy" and to say this, CA will sign this public key with its own private key. What if CA has trusted some fake machine ? This then becomes the CA's fault. The question arises, how can a CA trust someone.
2. Once the user gets a certificate signed by a CA it trusts, the end-user can accept that it is talking to someone trustworthy.  

So, as i see it, "Trust" itself seems to rely on out-of-band things like "reputation", "group-think" and other metrics. This is one frequently cited paper. Trust thus, is a "chain". If any one in the chain is a fake, the whole trust chain breaks. Thus, one needs constant checks and confirmations that someone is trustworthy.

In other words, the learning is that "trust" has to be earned, and further that trust has to be retained and maintained. Also one must note that "trust" is a human emotion, and we create all these systems because we as humans want to get our work done by trustworthy sources i.e. sources that will help solve our problems and satisfy our desires.

In this sense, trust is a engineering problem. 

BWT

How do we make data more amenable to Run Length Encoding? Burrows-Wheeler Transform is one way.

Complex Logarithms

Following up on my post here, I came across another such fun stuff here. Although it is already typed on that page, im retyping it, with the chance of trying to elaborate a bit more. The argument goes as follows:

1. We know that e^(i*theta) = cos(theta) + i sin(theta)
2. now, if theta = pi radians, then, we know that e^(i Pi) = cos(Pi) + i sin (Pi)
3. Now, cos(Pi rad) = cos (180 deg) = -1, and sin(Pi) = 0
4. so, e^(i Pi) = -1
5. now, square on both sides, so we get:
6. e^(2 i Pi) = 1
7. now take ln on both sides, so as to get
8. 2 i Pi = 0

clearly this is absurd, so something strange must be going on when taking a log of a complex number (step 7). and it turns out that yes, indeed this is a tricky situation, and this leads us to the topic of "Complex Logarithms". Essentially what is going on here is the following (as Wikipedia explains): A logarithm of a complex number essentially has "infinite" answers. (kind of like "aliasing"). Will revisit this page soon.

Valgrind !

Valgrind - awesome stuff :-)

Need to follow up on this ...

Nagle & delayed ACKs

Interesting discussion how Nagleing (goal is to avoid sending "tinygrams" to the peer, implemented by filling the sender buffer (delaying the "send") till an ack of a previous send is received) - and delayed ACKs (on the receiver side, do not immediately send an ACK, but delay it, so that the ack can be piggybacked on something the receiver app wants to send) can cause TCP performance problems. See this and this.

Note of course, how the tinygram issue is different from the Silly Window issue (tinygram - TCP window (as advertised by the peer) is almost empty and silly-window (TCP window is almost full).

Of course, no big deal in retrospect ... but interesting i thought...


(Another interesting thing to note is that the so-called "congestion window" is a way where the sender does not fill up the whole receiver's advertised window at once, but fills  it up slowly (the so called cwnd growth function)) 

Generating Silence?

What is of interest to me is implementing a device that does the following:

music playing loudly -----> pressure waves ---> mic---> computer

what should happen is:

music playing loudly ---> pressure waves --->

device that emits "negative" waves --> superposition -->

mic -> computer

Clearly this is too ambitious(big a bite), so maybe need to make some simplifying assumptions. Let me try to see if i can get some basic stuff working at least ! Well of course, the end goal is to have the "ear" instead of a microphone, but that might be actually beyond me right now. Will update this in the future.

A list of interesting products

Some hardware and software products i came across and liked:

1. Watching TV cheaply: http://www.hulu.com/plus and http://www.roku.com/roku-products + netflix.
2. Personal Cell Towers and Cell Phone Signal Boosters
3. Also came across Wolfram Alpha, which offers very interesting statitics e.g. See "Cisco Vs Akamai Vs Google Vs Apple" here. How cool is that ?

Video Streaming

Video streaming (where streaming means that someone is producing data , and someone else is consuming it) generally follows these two approaches based on the "subscription" type:

1. Push model of viewing data - e.g. i "subscribe" for a newspaper, and the newspaper is "pushed" to my house. Similarly, if clients subscribe to some multicast addresses, servers will push data to multicast addresses using UDP (or RTP). Client-server is unicast, but server-client is SSM or ASM. These days apparently one can do multicast on RTMP.
2. Pull model of viewing data - e.g. go to a newspaper stand to buy newspapers, i.e. no pre-decided "subscription". Clients will ask for chunks (i.e. ask the server to transmit the chunk) of data from server using HTTP, RTSP, other signaling mechanisms (e.g. RTCP) i.e. one is a streaming channel, and one control channel. These are unicast messages both ways. Note that the "chunk" here may be the entire size of the video file. If one wants to do "adaptive" rate control streaming, then one may have smaller chunks and ask more chunks as deemed necessary. 

Apple HLS may be described as a pull model. (here is a sample HLS stream )

IPTV on the other hand could be described as using the push model, where clients just ask for the data transmission to start (via IGMP join or via RTSP) , and the server then pushes data to the multicast.

I am not sure if RTMP is a push or a pull model. I am guessing it is a push model. 

Cisco Videoscape/Apple TV/Google TV/:

Cisco Videoscape, Apple TV,  Google Tv is the merging of TV and internet.

Today, "television" (unlike internet video) has been a 'real-time' system i.e. content is buffered for a small jitter-buffer (maybe a few seconds max.) & attempted to be repaired, but IF it happens so that there are gaps in the content, today, one sees the occasional screen-jitter i.e. today, TV content on screen is not frozen with a "buffering..." thing.

Thus, if one wants to provide a TV-like experience, one would have to create UDP streaming APIs (or loss-tolerant-TCP which is in other words: TCP Friendly UDP). Of course, this means that VQE like solutions can still be useful for these applications. Of course, this is just one way -- the other and probably the more attractive method is to use Adaptive Bitrate Streaming (ABR), and TCP, and a pull mechanism based on chunks of the video.

Youtube today uses HTTP Pseudo-Streaming using lightpd servers +  RTMP (See this and this )  + HTML5 + can even work with RTSP (Actually see this video)

Signaling Protocols:

RTSP:

Originally developed as a 'remote control' mechanism, and is a "stateful" protocol. Client has 4 states (init, ready, playing, recording) and server has 4 states too (init, ready, playing, recording). This was a good intro.
HTTP/RTMP/MMS are also used for signaling

Transport protocols:
HTTP (over TCP, rarely UDP), RTP/RTCP over UDP (rarely over TCP), RTMP (/optionally over HTTP) using TCP/UDP, MMS

Anyway this was a nice link comparing the different streaming protocols and their features.

Overview of Adobe Streaming tech

Actionscript vs. Javascript:
http://answers.yahoo.com/question/index?qid=20081212142558AAluL6n

SWF vs. FLV:
while we are on this topic, it is useful to know the difference between a SWF(player/metadata) and a FLV(data) (see this). This is a somewhat basic beginner kind of a question. Here is a link to see how Flash Video is distributed

RTMP:
Note that just by using SWF and FLV over HTTP video streaming can be achieved - what we call as "progressive download" of the FLV.
Adobe created another solution for streaming called RTMP. RTMP is used to talk from the player (running in the browser) with the server, and eventually send the FLV video with a difference that the client can jump to any location.

Youtube does use RTMP for storing video using RTMPT (see this). However, while streaming, Youtube used chunked HTTP transfers,

Apple Streaming tech:

HLS

Blog link

http://thedailyreviewer.com/top/rationality

Nice blog i came across. Note of course that one should not feel threatened by "rationality" etc, as i mentioned here, i.e. there is more to life than "rationality"/"problem-solving".

Computing

Just making a note of the things that one might want to consider while working on a career in Computing.

1. http://www2.research.att.com/~dsj/nsflist.html#Intro: A quick high-level overview of the state of the art in the area of computer science
2. http://en.wikipedia.org/wiki/Gödel_Prize
3. http://en.wikipedia.org/wiki/Turing_Award
4. http://en.wikipedia.org/wiki/List_of_computer_science_conferences

All of these as a measure of what has received recognition in the recent past (as a sign of which areas being investigated have received attention (and probably funding?)) and probably a good place to start working on (i.e. might receive support from other interested parties, unlike doing one's own's stuff in obscurity) ?

An imaginary number "j" is NOT sqrt(-1) !

I was shown the following proof a few days back and it left me puzzled:

1 = 1

also,

-1 = -1

Now lets divide both sides by 1. Thus:

-1/1 = -1/1

thus,

1/-1 = -1/1

Now lets take the square root on both sides (i.e. raise to 1/2. When i use the word "sqrt", what i mean is raising it to (1/2))

sqrt(1/-1) = sqrt(-1/1)

sqrt(1) /sqrt(-1) = sqrt(-1)/sqrt(1)

Lets call

x = sqrt(1) (which means, x = (1)^(1/2))

y = sqrt(-1), (which means, y = (-1)^(1/2))

then we have:

x/y = y/x

or,

x^2 = y^2, and thus

-1 = 1

Clearly this is absurd, so what went wrong ?

We can see that we are substituting x = 1^(1/2), which is supposed to mean that x^2 = 1, but x^2 = 1 means that x could as well have been - 1 i.e. - (1^(1/2)). Similarly, if we substitute y as sqrt (-1), then y^2 = -1, so y = +/- sqrt(-1). Essentially, if we call sqrt(1) as x, we must also understand that -x is also sqrt(1), and as a result the trouble with this solution is that after a stage it become "ambiguous".

On similar lines, if we define 'j', the imaginary number as +sqrt(-1), we face the following problems:

A) j^2 = j * j = sqrt(-1) * sqrt (-1) = ((-1)^(1/2))^2 = -1

B) j^2 = j * j = sqrt(-1) * sqrt (-1) = sqrt (-1 * -1) = sqrt(1) = +/- 1

i.e. ambiguous, and this is the reason we define j^2 = -1 (and j = +/- ((-1)^(1/2))). In fact Wikipedia is also careful about defining the imaginary number in this way (http://en.wikipedia.org/wiki/Imaginary_number) i.e. basically that we note that by this definition, j = +/- sqrt(-1) (and not j = + sqrt(-1)), so when someone uses e^(jtheta), it means e^((+/- ((-1)^(1/2)) * theta) -- kinda sucks -- but we have notation, to help us get used to this mess.

Thus we must be careful in defining the imaginary number as a "imaginary" square with area -1.

in a land that uses square coins, and if we owe -5 dollars to someone, we really owe 5 "imaginary" square coins. Someone can always argue that these coins are "imaginary" and impossible to "feel" by the senses, so there is no way one can give such a coin. However, we DEFINE a way to end this debt, by saying that giving a "real" coin, eliminates the imaginary coins' debt.

Other ways of looking at the imaginary number is as a "rotation" in the complex plane (using x+iy), but we sometimes loosely use j = sqrt(-1) and in my opinion it is not right i.e. has the potential to cause quite a bit of confusion.

Now whats with this another blog

Aims at two goals

1. The other blog is meant to be a "lessons learnt", i.e. as such i do not intend to write stuff there unless i have spent a significant time thinking about stuff, so the half-baked ideas i am hoping to put them up here, why all this fuss about making this stuff public, when i can as well make all of this private ? Well, a couple of reasons -- making it public increases my stake in this stuff (making me actually revisit these ideas) and the idea of putting this online is because i find it convenient to put up links to pages this way (e.g. Wikipedia, other pages, papers etc.).
2. Also, another secret goal is to work on Mathematics & related issues in Computer Science, EE, and other areas that i face professionally, i.e. intend not to put high-level philosophy talk here.

This blog is just my personal blog (in a manner similar to the blogs of others)