Difference between revisions of "WebFund 2013F Lecture 7"

From Soma-notes
Jump to navigation Jump to search
Line 1: Line 1:
Audio from the lecture given on September 30, 2013 is available [http://homeostasis.scs.carleton.ca/~soma/webfund-2013f/lectures/comp2406-2013f-lec07-30Sep2013.m4a here].
Audio from the lecture given on September 30, 2013 is available [http://homeostasis.scs.carleton.ca/~soma/webfund-2013f/lectures/comp2406-2013f-lec07-30Sep2013.m4a here].
==Note==
September 30
* cookies
** text document
** saves info on what you were doing on site
* stateless
** HTTPS
** SSH
* what can server do to keep track of client?
** Cookies!
*** Something the server sets
*** sent along later
** Encode information in the url itself
*** that will say what this session identifier is
* Server can't trust anything the client sends
* webrequests are stateless
* How to make sure the user doesn't mess with your cookies
** have to be encoded
*** cookies should look like garbage
***if you can hand edit the cookie you are doing something really dumb
* state is being passed around in url
* remote procedure calls
** a program calling another and passing stuff around
** ie. like buttons on webpages
* [[File:http://homeostasis.scs.carleton.ca/wiki/index.php/File:Sept30.jpg]]
* block
** running (on a 4 core processor you could have 4 processes running simultaneously)
** ready (waiting for a free processor)
** waiting on I/O (blocked until something has happened)
* synchonous I/O
** read (b)
** what happens here?
*** Program went to sleep and is woken up
*** could be doing other things here instead of giving up the CPU!
*** Not efficient to switch between processes
** scanf(b)
*** only makes sense after read is completed
* in node when you do any I/O code it returns immediately
** asynchronous
** callbacks solve asynchronous promblem
*** read(s, b, callback)
**** do the read request, and when it's done, here is the code to run encoded in this callback
* node acts like a dispatcher
** constantly routing data
* classic callback in node
** listen line
*** has a port number + callback function

Revision as of 17:59, 8 November 2013

Audio from the lecture given on September 30, 2013 is available here.

Note

September 30

  • cookies
    • text document
    • saves info on what you were doing on site
  • stateless
    • HTTPS
    • SSH
  • what can server do to keep track of client?
    • Cookies!
      • Something the server sets
      • sent along later
    • Encode information in the url itself
      • that will say what this session identifier is
  • Server can't trust anything the client sends
  • webrequests are stateless
  • How to make sure the user doesn't mess with your cookies
    • have to be encoded
      • cookies should look like garbage
      • if you can hand edit the cookie you are doing something really dumb
  • state is being passed around in url
  • remote procedure calls
    • a program calling another and passing stuff around
    • ie. like buttons on webpages
  • File:Http://homeostasis.scs.carleton.ca/wiki/index.php/File:Sept30.jpg
  • block
    • running (on a 4 core processor you could have 4 processes running simultaneously)
    • ready (waiting for a free processor)
    • waiting on I/O (blocked until something has happened)
  • synchonous I/O
    • read (b)
    • what happens here?
      • Program went to sleep and is woken up
      • could be doing other things here instead of giving up the CPU!
      • Not efficient to switch between processes
    • scanf(b)
      • only makes sense after read is completed
  • in node when you do any I/O code it returns immediately
    • asynchronous
    • callbacks solve asynchronous promblem
      • read(s, b, callback)
        • do the read request, and when it's done, here is the code to run encoded in this callback
  • node acts like a dispatcher
    • constantly routing data
  • classic callback in node
    • listen line
      • has a port number + callback function