acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

On Fri, Jul 9, 2010 at 11:11 PM, Aditya Manthramurthy
<aditya.mmy@xxxxxxxxx>wrote:

>  On Saturday 10 July 2010 02:15 AM, Karthik Swaminathan Nagaraj wrote:
>
> It looks like we are definitely on the same page!
>
> On Wed, Jul 7, 2010 at 2:55 PM, Aditya Manthramurthy <aditya.mmy@xxxxxxxxx
> > wrote:
>
>> Hi all,
>>
>> After what seems to me to be a confusion because of miscommunication,
>> we've developed a picture to show the various components of the s/w. It is
>> now linked from the wiki page at:
>> http://www.nkarthiks.info/acmeattic/index.php?title=Implementation
>>
>> Please go through it. Let's discuss it at least using a clearer set of
>> terms now.
>>
> Why HTTPS?: (Lets forget the web interface for a moment here) Why should
> the client daemon talk to the server using HTTPS? Isn't an SSL connection
> over TCP sufficient? I personally do not want to involve HTTP in a
> client-server communication where there is *no* web browser involved.
>
>
> I am advocating HTTPS because the particular port we use in a TCP
> connection is likely to be closed in most restricted networks (think
> universities, and corporate networks). Not so for HTTPS. Also, in a HTTPS
> connection, the certificate's authenticity is automatically checked with the
> certifying authority by the browser. I don't know how we would do this with
> plain TCP with SSL/TLS.
>
HTTPS [1] just provides HTTP over SSL (as simple as that). Its the browser's
responsibility to verify the certificates. Mozilla has put up a list of
certificates that it uses [2] (from popular Certificate Authorities). If we
initiate a connection using SSL, the client software obtains the server's
certificate and verifies it against one of these certificates that our
application would carry. (We do not have a browser in this picture).

If our Server Core module were to listen on the HTTPS port (443), then its
actually hijacking a "well known" port for our application. This means that
the same machine cannot handle an HTTPS web server.
If you are referring to writing the server core module as a web application,
it sounds weird to write a non-www application as a web application. Also, I
am sure DropBox and SpiderOak do not use HTTPS for client_app-server_app
interaction.

About port blocking, are you sure universities give a public IP to a
computer but block ports? In all the circumstances I see here at Purdue and
DSL users at home, they are either given a Public IP with full port access,
or are kept behind a NAT which means you cannot access the machine from
outside anyway.

>
>
>  IPC: When there is network, why IPC? This limits future scalability.
>
>   Ah, that is good. Maybe some custom protocol over TCP can be used?
>
Yes, custom protocols over TCP/SSL. Its actually simple - let me give you a
gist of the idea here.
A "Message" (protocol buffer, etc.) is encoded as a byte array. This is sent
over as <message-length-in-32-bits><message>. This allows us to handle any
type of message, and our job is to define a state machine using these
messages. Each message would have a handler at the receiving end which is
called on receipt.

>
> --
> Aditya.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> More help   : https://help.launchpad.net/ListHelp
>
>
[1]: http://en.wikipedia.org/wiki/HTTP_Secure
[2]: http://www.mozilla.org/projects/security/certs/included/


-- 
Karthik