Category Archive網路科技



未分類 &軟體 &網路科技 dada on 十月 28, 2011

噗浪機器人範例程式 - 使用 Plurk API 2.0

這篇文章說明如何用 Plurk API 2.0 自己寫一個噗浪機器人

(本文同步發表於 噗浪官方部落格)

噗浪大部分的機器人仍然使用 Plurk 1.0 撰寫,甚至有一部分機器人使用的是非官方的 API,這篇文章將簡介如何使用 Plurk API 2.0 OAuth 的方式開發機器人程式,同時,這個範例也使用 Plurk Realtime API (Comet Push) 的方式來追蹤時間軸,避免給伺服器帶來過多的負擔

由於 Plurk API 2.0 使用 OAuth 方式,所以啟動機器人之前,您必須先獲得以下四個參數

  • App Key
  • App Secret
  • Access Token
  • Access Token Secret

獲得 App Key 及 App Secret 的方式很簡單,首先先註冊一個新的噗浪帳號用來跑這個機器人,然後登入新帳號後,開啟以下這個連結:

http://www.plurk.com/PlurkApp/

按下「註冊新的應用服務」,填寫關於你的程式的資料,其中 OAuth callback 保持空白即可

註冊完畢後就可以看到你的應用程式列表

然後按下「編輯」這個按鈕,就可以看到以下畫面:

這邊我們就可以得到 App Key 以及 App Secret 了

接下來要進行 OAuth 的授權驗證來取得 Access Token 及 Access Token Secret

按下「測試工具」來開啟 OAuth 的 Test Console

首先按下「Get Request Token」來取得暫時的 Request Token,
接下來按下「Open Authorization URL」來開啟授權頁面:

按下「是,我要授權」後,會得到一個認證碼:

把這個六位數的認證碼記下來,然後回到 Test Console,
按下「Get Access Token」,這時會提示您輸入認證碼

把您剛剛記下來的數字填進去,按下「確定」後,
就可以得到永久有效的 Access Token 及 Access Token Secret 了

然後你就可以開始寫程式了,下面是一個用 Python 寫的噗浪機器人,
把其中 APP_KEY, APP_SECRET, ACCESS_TOKEN, ACCESS_TOKEN_SECRET 置換掉即可

這個程式需要使用到 plurk-oauth 這個 Python library,
請把 plurk_oauth/ 這個目錄下的檔案下載回來跟你的程式放在一起就可以了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#!/usr/bin/python
# -*- coding:utf-8 -*-
 
import re
import json
import urllib2
 
from PlurkAPI import PlurkAPI
 
plurk = PlurkAPI('APP_KEY', 'APP_SECRET')
plurk.authorize('ACCEESS_TOKEN', 'ACCESS_TOKEN_SECRET')
 
comet = plurk.callAPI('/APP/Realtime/getUserChannel')
comet_channel = comet.get('comet_server') + "&new_offset=%d"
jsonp_re = re.compile('CometChannel.scriptCallback\((.+)\);\s*');
new_offset = -1
while True:
    plurk.callAPI('/APP/Alerts/addAllAsFriends')
    req = urllib2.urlopen(comet_channel % new_offset, timeout=80)
    rawdata = req.read()
    match = jsonp_re.match(rawdata)
    if match:
        rawdata = match.group(1)
    data = json.loads(rawdata)
    new_offset = data.get('new_offset', -1)
    msgs = data.get('data')
    if not msgs:
        continue
    for msg in msgs:
        if msg.get('type') == 'new_plurk':
            pid = msg.get('plurk_id')
            content = msg.get('content_raw')
            if content.find("hello") != -1:
                plurk.callAPI('/APP/Responses/responseAdd',
                              {'plurk_id': pid,
                               'content': 'world',
                               'qualifier': ':' })

執行方式:

# python my-robot.py

這個範例程式作的事情很簡單,就是一個無窮迴圈,首先每次都會先接受所有成為朋友的請求,然後看看有沒有新的噗,如果有新的噗,而且內容有 'hello' 字串的話,就會自動回覆一個 'world' 字串

提醒大家,噗浪並不反對機器人的存在,但使用這個範例程式請注意以下幾點:

  1. 建議使用新的帳號,不要用原有的帳號
  2. 機器人請勿主動去加網友為朋友
  3. 機器人請勿去關注(追蹤)任何其他網友
  4. 請勿自動回覆未成為機器人的朋友所發的噗
  5. 請勿張貼廣告訊息
  6. 請注意回覆頻率,以不過度干擾使用者的方式為原則

網路科技 dada on 九月 22, 2011

Linode 新增東京機房 / Hinet FTTB 50M 測試結果

http://blog.linode.com/2011/09/19/linode-cloud-asia-pacific/

直接貼從家裡 Hinet FTTB 50M 的測試結果

--- tokyo1.linode.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 52.412/54.710/59.112/2.365 ms

--- dallas1.linode.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 196.465/198.960/203.051/2.565 ms

--- fremont1.linode.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 144.085/146.395/150.149/2.265 ms

wget -O /dev/null http://tokyo1.linode.com/100MB-tokyo.bin
--2011-09-22 00:10:20-- http://tokyo1.linode.com/100MB-tokyo.bin
Resolving tokyo1.linode.com... 106.187.33.12
Connecting to tokyo1.linode.com|106.187.33.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'
2011-09-22 00:11:50 (1.11 MB/s) - `/dev/null' saved [104857600/104857600]

wget -O /dev/null http://dallas1.linode.com/100MB-dallas.bin
--2011-09-22 00:12:29-- http://dallas1.linode.com/100MB-dallas.bin
Resolving dallas1.linode.com... 69.164.200.100
Connecting to dallas1.linode.com|69.164.200.100|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'
2011-09-22 00:17:50 (320 KB/s) - `/dev/null' saved [104857600/104857600]

wget -O /dev/null http://fremont1.linode.com/100MB-fremont.bin
--2011-09-22 00:19:56-- http://fremont1.linode.com/100MB-fremont.bin
Resolving fremont1.linode.com... 64.71.152.17
Connecting to fremont1.linode.com|64.71.152.17|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'
2011-09-22 00:24:05 (412 KB/s) - `/dev/null' saved [104857600/104857600]

網路科技 dada on 三月 24, 2009

畸形的台灣網路環境 (IP Peering)

今天的一則新聞「拒付互連費》台灣大 槓上中華電

好玩的是,不專業的聯合報記者把 1M (Mb/s) 的頻寬單位,自作主張翻譯成 "公尺"

udn-joke

這篇新聞爭論的其實是 "peering" (網路互連),無關 "transit" (借道連外),同時也與最後一哩 (last mile) 的電路壟斷無關。所以很多網友說到台固想用中華電信的國際頻寬不付錢,或者是批評台固沒有自建電路,這都跟這條新聞完全無關

雖然已經不是在 ISP 業界了,不過看到這則新聞還是有深深的感慨,固然 ISP 對於中華電信的反彈有其利益考量,不過真正該思考的是:中華電信造成的不公平競爭,使得網路內容提供業者 (ICP) 面臨一個被壟斷而無法公平競爭的網路環境。

Peering (網路互連) 指的是兩個 ISP (網際網路供應商) 相互連結、互通有無的情況,例如 ISP-A 的用戶可以經由 peering 來直接存取放置在 ISP-B 內的網站,反之亦然

如果兩個 ISP 之間沒有 peering 的話,就必須透過 transit 經由其他 ISP 轉接過去,不然就是透過 網路交換中心(IX) 相互連接。

以香港為例,香港網路交換中心 (HKIX) 就扮演了一個很重要的角色,從下面這張圖可以看到,HKIX 的平均流量高達 40-50 Gb/s
hkix

這是日本 JPIX 的流量圖,平均流量高達 75Gb/s 以上:

然後我們來看看台灣的情況,有中華電信在背後當黑手的 台灣網際網路交換中心 (TWIX) 的流量是這樣的:
twix

你沒看錯,TWIX 的流量平均只有 3Gb/s

TWIX 的線路連接情況可以從 TWNIC 的「連線頻寬查詢系統」查詢,簡單的說,TWIX 與各大 ISP 都有連接,但是擁有最多內容的中華電信卻只有 1Gb 的小水管連接到 TWIX。由於需求遠大於供給,逼迫各 ISP 必須直接拉線跟中華電信購買頻寬,以滿足自己的用戶所需

就國際上的慣例而言,兩家 ISP 互連 (peering),會由淨流量輸入者付錢給淨流量輸出者,所以擁有比較多網站內容的 ISP 就有可能賺取這樣的 peering 費用

花錢買 peering 或許是合理的,尤其中華電信擁有國內最多的內容(因為用戶多),但重點在於要花多少錢,中華電信的定價是否合理呢?

實際上來看,中華電信是三頭賺的:

網路內容業者(ICP)為了讓自己的網站用戶能有比較好的網路體驗,怕輸在起跑點上,所以必須花大錢租用中華電信的機房,把自己的網站 colocation 在中華電信

其他的 ISP 業者為了讓自己的寬頻用戶可以很順暢連結放在中華電信的網站,所以也要花大錢跟中華電信買頻寬

更重要的是,HINET寬頻用戶付了不算便宜的上網費用,卻造就了中華電信這樣的寬頻龍頭怪獸,並讓中華電信拿著當武器去壓迫其他 ICP 及 ISP...

依照 peering 的國際慣例計費方式,ISP 業者如果能夠爭取到比較好的內容業者,或許可以減少一些與中華電信 peering 費用,所以 ISP 業者就會盡力去以優惠價格爭取 ICP 內容業者進駐,ICP 得到扶持後,才有能力提供更多的服務給寬頻用戶,這可以使得寬頻用戶、ISP、ICP 三者間產生正向循環,這樣才能扶植網路內容產業的蓬勃發展:

isp1

但台灣因為中華電信的壟斷,導致這樣的循環無法成立,甚至變成惡性循環:

isp2

所以不但寬頻費用居高不下,網路內容業者(ICP)也無法藉由正向循環得到扶持

國內最成功的 peering 輸出國應該是遊戲橘子,遊戲橘子有自己的 AS Number (自治系統號碼),藉由「天堂」這一款超人氣的線上遊戲,使得國內的一些 ISP 都不敢怠慢自己的寬頻用戶,必須乖乖掏錢出來跟遊戲橘子的代理商~和信超媒體買頻寬 (和信超媒體曾經投資過遊戲橘子),不過,中華電信當然還是不會買的,因為他挾兩百萬的寬頻用戶自重

但很可惜的,國內似乎看不到其他內容業者能夠很成功的如法炮製

這正所謂的「養、套、殺」,網路內容業者(ICP),如果一開始就屈服於中華電信的壟斷壓力,怕自己的用戶擁有不好的寬頻體驗,所以把自己的網站放在中華電信。等到網站越長越大,網路內容業者卻反而更擔心如果隨意搬移到其他 ISP 會導致用戶因為無法順利連結而大量流失用戶,所以就被中華電信套住了,之後當然就任意被獅子大開口,完全是賣方市場。想要多租個機櫃都可能跟你說空間不夠,要你配合搬去偏遠的機房。反而是其他 ISP 的機房空在那邊養蚊子

ISP 究竟能不能靠著爭取更多優質 ICP 業者的進駐而降低付給中華電信的 peering 費用呢? 在這個壟斷的環境中,事實上是很難的

過去和信超媒體(GIGA)提供給寬頻用戶的「免費個人網頁空間 (PWP)」曾經擁有非常大的流量輸出,這使得和信超媒體與中華電信 peering 的輸出與輸入不相上下,但中華電信認為這些都是垃圾流量而拒絕提供免費的 peering

曾有一次,GIGA 在國外租了個空間放 PWP 的 Proxy,然後把中華電信用戶連結 PWP 的需求經由國外 Proxy 餵回給中華電信,這一次據說就把中華電信的國際頻寬塞爆了。這個例子更顯示出中華電信對於 peering 定價的不合理性,把 proxy 放在國外餵回給中華電信,都比在國內 peering 餵給中華電信便宜

一個壟斷的網路環境會使得很多情況變得不合理,ICP 無法得到合理的回饋,ISP 也因為無力負擔 peering 費用而必須向 ICP 收取比較高的費用,造成惡性循環

無名小站在2006年曾經想如法炮製遊戲橘子的成功經驗 (後來因為被 Yahoo 買下而作罷),無名小站那時想藉由自己用戶的壓力去逼迫中華電信屈服。但事實證明在中華電信屈服前,無名小站自己必然也會面對更大、來自原有用戶反彈的壓力!

要求中華電信無條件地提供免費 peering 可能是緣木求魚,或許也會有更多爭議,但還是期待中華電信能以其電信龍頭的高度,設法讓國內 ISP 及 ICP 的產業鏈更加健全,而不是只想要吸乾所有人的血。

遊戲橘子的成功有其時空背景,我不認為未來還會有其他家內容提供業者有這個膽識與中華電信對抗,這次 ISP 業者的反彈事實上也不是第一次了。無論如何,想要反轉這個畸形、被壟斷的網路環境,就只能期待 NCC 能有一點作為了。否則的話,台灣是永遠不可能養出像 Youtube 這樣的網站的!

相關討論:

相關新聞:

網路科技 dada on 二月 20, 2009

AdSense for Domains (在未使用的網址上放廣告)

Google 推出了 AdSense for Domains (AdSense 網域廣告)

引用 Google 對此產品的說明:

AdSense 網域廣告可讓發佈商在未使用的網域上顯示相關內容,以協助使用者取得所需的資訊。

使用者通常會在網址列中輸入網域,或按下無效連結而連上沒有內容的網站。AdSense 網域廣告可提供連結、搜尋結果、廣告和其他內容,而不是「建置中」網頁或 404 錯誤。我們的做法是使用語意技術,根據網域名稱來指定目標。當使用者與您網站上的廣告互動時,您便可以賺取收益。

我猜這個產品推出後,獲利最大的應該是各家 registrar (網址註冊商) 吧 :roll:

可能有很多人會去註冊一些網址來專門放 AdSense for Domains 廣告賺錢,畢竟網址年費還算低,好一點的網址光放 AdSense for Domains 廣告搞不好就可以回本了,而且不用自己找機器放網頁,只要把網址 DNS 指過去 Google 的伺服器即可

根據 Google 的說明,DNS 只要設定好 CNAME 以及四筆 A 記錄即可,Google 也提供了各大網域註冊商(如 GoDaddy)的詳細設定方式

www   CNAME   pub-xxxxxxxxx.afd.ghs.google.com.

@   A   216.239.32.21
@   A   216.239.34.21
@   A   216.239.36.21
@   A   216.239.38.21

當然你也可以設定更多個 CNAME 就是了...

同時,對於網域廣告你還可以設定一些關鍵字,可以更精確選擇你想要顯示的廣告

另外「AdSense 網域廣告計劃政策」裡面有提到

Google AdSense 網域廣告非常重視商標所有人的權利。我們希望所有廣告客戶、使用者和商標所有人都瞭解 Google 審查 AdSense 網域廣告聯播網中商標侵權案件的程序。如果 Google 發現任何包含商標 (或類似拼字) 的網域名稱,便會將該網域從 AdSense 網域廣告聯播網中移除

所以如果想要用與知名網站類似的網域名稱來使用 AdSense for Domains,也許會被移除吧

網路科技 dada on 八月 28, 2008

Bye Bye ISP - 和信超媒體(GigaMedia)賣掉了 ISP 部門

和信超媒體的母公司 GigaMedia 今天宣佈以 2000 萬美元將 ISP 部門 (包含和網寬頻 KBT) 賣給中嘉網路,如果接下來兩年出售的部門達到業績目標,還可以另外再取得 500 萬美元

相關新聞:

2000年進入 和信超媒體 工作時,當時公司最主要的業務就是 Cable Modem 寬頻上網,但受限於許多先天及後天因素,發展得並沒有很好。2001年開始進入 ADSL 的市場,但也因為中華電信獨占電路的關係,競爭還是處於不利地位。2006年 將 ADSL 部份賣給了現在的天空傳媒 (原Webs-TV) 之後,GigaMedia 還是持續經營著 Cable Modem 業務(和信超媒體)以及企業專線市場(和網寬頻)

中嘉網路原是和信關係企業,但在 安博凱MBK 入主之後,外資目前也佔了很大一部份股權。中嘉系統下的有線電視業者原本的 Cable Modem 寬頻上網服務就是由和信超媒體提供的,但是後來因為種種因素,中嘉還是推出了自己的 Cable Modem 品牌 (互動BB),與和信超媒體 GIGA 品牌的 Cable Modem 變成競爭又合作的奇妙關係...

GigaMedia 事實上近幾年已經把精力幾乎都投注在線上遊戲的發展,ISP 網路部門的出售也是遲早的事。 ISP 部門尤其是企業專線市場與有線電視業者整合後,應該是能夠有更好的發展的!

在新聞發佈的這時候,我正在上海出差,看到這則新聞其實是有點百感交集,當初會加入這個公司,也是對 ISP 所能夠提供的服務有濃厚的興趣。從整套的寬頻網路管理系統 (內部稱 SIMBA)、ADSL 服務、網路相簿WebAMP,都留下了我許多參與的心血...

世事是很難預料的,沒想到我最終還是回到網路遊戲這一塊,我研究所兩年的主要研究 :wink:

無論如何,還是祝福 ISP 部門的同事們!

~ 希望我們的努力能讓你們手中的 option 價值更高一點 :razz:

延伸閱讀:

後一頁 »