stanford-oval/wikipedia huggingface dataset:
SILK LABO
作品 > その他

| 発売日 | 内容 | 出演者 |
| --- | --- | --- |
| 2009/7/29 | 『an・an』特別付録DVD「Girl's pleasure」 | 一徹 原紗央莉 |
| 2011/9/7 | 『an・an』特別付録DVD「Orgazm Lesson」 | 一徹 周防ゆきこ |
| 2012/9/7 | 『an・an』特別付録DVD「Love Switch」 | ムーミン 加藤ツバキ 倉橋大賀 栗林里莉 一徹 友田彩也香 |
| 2013/8/9 | 『an・an』特別付録DVD「3 Ways of Love 3つの愛のカタチ」 |  |
| 2014/8/8 | 『an・an』特別付録DVD「Love Moment ~そのとき、彼が欲しくなる。」 | 一徹 渡部拓哉 多田ヒロキ |
| 2015/8/7 | 『an・an』特別付録DVD「in her case そのとき、彼が欲しくなる。」 | 一徹 有馬芳彦 渡部拓哉 |
| 2016/8/10 | 『an・an』特別付録DVD「in her case ずっと、彼を求めてた」 | 一徹 有馬芳彦 東惣介 |
| 2017/8/9 | 『an・an』特別付録DVD「in her case -最高の一夜-」 | 一徹 有馬芳彦 夏目哉大(向理来) |
| 2018/8/8 | 『an・an』特別付録DVD「Love in Comfort 優しさに包まれて」 | 有馬芳彦 北野翔太 東惣介 |
| 2019/8/7 | 『an・an』特別付録DVD「「with You」愛はいつでもそこに」 | 橘聖人 上原千明 東惣介 |
| 2020/8/5 | 『an・an』特別付録DVD「あなたといる部屋　AT HOME SELECTION」 | 新型コロナウイルスによる緊急事態宣言の影響で、 過去作品より収録 :   [2015年 ep.1] 一徹、雪見えみる  [2016年 ep.2] 有馬芳彦、北川エリカ  [2018年 ep.3] 東惣介、古川いおり  副音声 : 一徹、牧野P  |
| 2021/7/14 | 『an・an』特別付録DVD「Room for Two 愛しい距離感」 | 及川大智×美咲かんな  [episode.1] すっぴんコンプレックス  [episode.2] ふたりのラブシグナル  [episode.3] 停電の夜 |
| 2022/8/10 | 『an・an』「愛とSEX/菊池風磨」 | 東雲怜弥 |
| 2023/8/9 | 『an・an』「愛とSEX/渡辺翔太」 | 保志健斗 |
| 2024/8/21 | 『an・an』「愛とSEX/田中樹」 | 大空太陽 |
作品 > GOODS

| 品番 | 発売日 | 品名 |
| --- | --- | --- |
| EC-SILKG-001 | 2011/12/5 | SILKY BODY SOAP |
雑誌

GINGER 12・1月合併号 雑誌コード05253（幻冬舎・2023年10月23日発売）
イベント

※18歳以上の女性限定。
SILK LABO 1st Anniversary SUMMER FES 2010 in 阿佐ヶ谷LOFT A （2010年09月05日、阿佐ヶ谷LOFT A） - ゲスト：一徹・月野帯人・ムーミン
SILK LABO WINTER FES 2010（2010年12月11日、阿佐ヶ谷LOFT A） - ゲスト：志戸哲也・月野帯人・ムーミン・一徹
SILK LABO「恋するサプリ－年下の彼－」発売イベント（2011年09月10日、秋葉原M's studio） - ゲスト：一徹・ムーミン
SILK LABO M's振替イベント『ツッキー全快おめでとう！』サイン会（2011年10月23日、SOD本社ビル1F） - ゲスト：月野帯人・ムーミン
SILK LABO SPRING FES 2012 ～in Naked　Loft～（2012年05月26日、Naked Loft） - ゲスト：一徹・月野帯人・ムーミン
SILK LABO present's Ittetsu♡Paradise vol.1 ～in Asagaya/Loft A～ （2012年10月6日、Asagaya／Loft A） - ゲスト：一徹
SILK LABO present's Ittetsu♡Paradise vol.2 ～in Asagaya/Loft A～ （2012年11月25日、新宿Naked Loft） - ゲスト：一徹
SILK LABO WINTER FES 2012 ～in 新宿 Naked Loft～ （2012年12月1日・2日、新宿Naked Loft） - ゲスト：一徹、月野帯人、ムーミン、倉橋大賀
SILK LABO present's「オトナ♡の保健体育～男女和解SP！」～in Asagaya／Loft A～ （2012年12月08日、Asagaya／Loft A）
京都高度技術研究所

| 公益財団法人京都高度技術研究所 |
| --- | --- |
 ASTEM棟
正式名称:  公益財団法人京都高度技術研究所
英語名称:  Advanced Science, Technology & Management Research Institute of KYOTO
略称:  アステム（ASTEM RI／KYOTO）
組織形態:  公益財団法人
所在地:   日本 〒600-8813 京都市下京区中堂寺南町134 北緯34度59分41.385秒 東経135度44分24.620秒﻿ / ﻿北緯34.99482917度 東経135.74017222度﻿ / 34.99482917; 135.74017222
法人番号:  3130005002942 
予算:  31億73百万円（2016年度）
人数:  172名（2016年4月1日時点）
所長:  阿草清滋
理事長:  西本清一
活動領域:  地域産業振興、ICT研究開発、産学公連携による研究開発支援
設立年月日:  1988年（昭和63年）8月9日
前身:  財団法人京都高度技術研究所
設立者:  京都市・京都府・産業界
所管:  京都府
下位組織:  #組織の節を参照
ウェブサイト:  http://www.astem.or.jp/
テンプレートを表示
京都市成長産業創造センター
公益財団法人京都高度技術研究所（きょうとこうどぎじゅつけんきゅうしょ、略称: アステム、ASTEM RI／KYOTO）は、京都の産業、科学技術の振興を目的として設立された研究機関。京都府、京都市、地元産業界、京都大学などを設立の中心とする公益法人である。
概要

ソフトウェア技術、システム技術等のICT（情報通信技術）を活用した先端科学技術の研究、開発、調査等を行い、科学技術の振興と地域社会の発展に寄与するとともに、ベンチャー・中小企業に対する総合的な支援を行い、京都市内の中小企業の振興と地域経済の活性化を図る活動を行っている。
1988年（昭和63年）08月 - 財団設立
2005年（平成17年）04月 - 株式会社京都ソフトアプリケーションの機能を統合
2009年（平成21年）10月 - 財団法人京都市中小企業支援センターと統合
2013年（平成25年）04月 - 公益財団法人化
基本財産

基本財産 - 3億円
京都市 - 1億円（33.3％）
京都府 - 5千万円（16.7％）
地元産業界 - 1億1千万円（36.7％）
その他 - 4千万円（13.3％）
施設 > ASTEM棟

住所 - 京都市下京区中堂寺南町134 京都リサーチパーク東地区内（北緯34度59分41.140秒 東経135度44分24.579秒﻿ / ﻿北緯34.99476111度 東経135.74016083度﻿ / 34.99476111; 135.74016083）
竣工 - 1989年（平成元年）9月26日
開所 - 1989年（平成元年）10月20日
構造 - 鉄骨・コンクリート造
規模 - 地上10階・地下1階、延床面積 7,074.58 m2
施設 > 京都市成長産業創造センター

住所 - 京都市伏見区治部町105 らくなん進都内（北緯34度56分21.148秒 東経135度45分6.988秒﻿ / ﻿北緯34.93920778度 東経135.75194111度﻿ / 34.93920778; 135.75194111）
竣工 - 2013年（平成25年）9月
開所 - 2013年（平成25年）11月1日
構造 - 鉄骨造及び鉄骨鉄筋コンクリート造
規模 - 地上5階・地下1階、延床面積 5,938.84 m2
沿革

1988年（昭和63年） - 京都府知事から財団法人京都高度技術研究所設立許可（財団設立）
1989年（平成元年） - 第1期VIL入居募集開始（ベンチャー企業支援開始）
京都リサーチパーク東地区内にASTEM棟竣工し開所（メカトロニクス・ICT分野の研究開発開始）
1995年（平成7年） - 京都市役所内のLAN運用管理を受託（自治体の情報ネットワーク[要曖昧さ回避]運営支援開始）
kyoto-Inet、kyoto-Pnet サービス開始
1996年（平成8年） - 情報網「洛中洛外」（スポーツ情報システム）稼働
1997年（平成9年） - 情報網「洛中洛外」（京都市観光文化情報システム）稼働
1999年（平成11年） - 京都市地域プラットフォーム事業開始（新事業創出支援体制の構築）
2000年（平成12年） - 創業準備支援室（スタートアップベンチ<StB>）開設
2002年（平成14年） - 地域新生コンソーシアム研究開発事業（経済産業省委託）の事業管理開始
知的クラスター創成事業（文部科学省委託事業）開始 （産学連携推進体制の本格化）
オスカー認定制度 開始 （中小企業の経営革新に対する支援開始）
2003年（平成15年） - 京都バイオ産業技術フォーラム設立
2004年（平成16年） - 京都市地域結集型共同研究事業（JST委託事業）開始
2005年（平成17年） - 株式会社京都ソフトアプリケーションの機能を統合
2006年（平成18年） - (独法)情報通信研究機構（NICT）より多言語観光情報プラットフォーム開発受託
2007年（平成19年） - プライバシーマーク付与認定
2008年（平成20年） - 知的クラスター創成事業（第II期）（文部科学省委託事業）開始
2009年（平成21年） - Mobileware開発センター・EtherCAT認証テストセンター 開設
財団法人京都市中小企業支援センターと統合（産業支援機能・体制の拡充）
イノベーション創出コミュニティ（STC3）事業開始
2010年（平成22年） - 京都市医工薬産学公連携支援オフィス 開設
2011年（平成23年） - 京都産学公共同研究拠点「知恵の輪」京都バイオ計測センター を KISTIC 内に開所
2012年（平成24年） - イノベーションネットアワード 2013 経済産業大臣賞受賞
2013年（平成25年） - ASTEM公益財団法人化
地域イノベーション戦略支援プログラム（文部科学省補助事業）開始
スーパークラスタープログラム（JST委託事業）開始
京都市成長産業創造センター（ACT Kyoto） を京都市伏見区に開所（新施設開設）
2014年（平成26年） - ASTEM開所25周年
2015年（平成27年） - 京都市ライフイノベーション創出支援センター 及び同支所開設
京都市ソーシャルイノベーション研究所（SILK）開設
歴代理事長

| 代 | 氏名 | 在任時期 | 就任時の役職 |
| --- | --- | --- | --- |
| 初代 | 堀場雅夫 | 1988年8月～2002年6月 | 株式会社堀場製作所 取締役会長 |
| 第2代 | 西川禕一 | 2002年7月～2005年3月 | 京都大学名誉教授、大阪工業大学学長 |
| 第3代 | 髙木壽一 | 2005年6月～2011年6月 | 元京都市副市長 |
| 第4代 | 森井保光 | 2011年7月～2012年5月 | 京都市企画監 |
| 第5代 | 西本清一 | 2012年7月～現在 | 京都市産業技術研究所理事長、京都大学名誉教授 |
副理事長

阿草清滋 - 南山大学大学院理工学研究科長、京都大学学術情報メディアセンター客員教授、名古屋大学名誉教授・客員教授
牧野圭祐 - 京都市成長産業創造センター センター長／京都大学名誉教授
上田誠 - 京都市産業観光局長
歴代所長

| 代 | 氏名 | 在任時期 | 就任時の役職 |
| --- | --- | --- | --- |
| 初代 | 大野豊 | 1988年8月～1992年3月 | 京都大学名誉教授 |
| 第2代 | 花房秀郎 | 1992年4月～1994年3月 | 京都大学名誉教授 |
| 第3代 | 松本吉弘 | 1994年4月～1998年3月 | 京都大学工学部教授、大阪工業大学情報科学部教授 |
| 第4代 | 西川禕一 | 1998年4月～2002年3月 | 京都大学名誉教授、大阪工業大学情報科学部長 |
| 第5代 | 池田克夫 | 2002年4月～2007年6月 | 京都大学名誉教授、大阪工業大学情報科学部情報メディア学科長 |
| 第6代 | 中村行宏 | 2007年7月～2014年3月 | 京都大学名誉教授、立命館大学総合理工学研究機構教授 |
| 第7代 | 阿草清滋 | 2014年4月～現在 | 南山大学大学院理工学研究科長、京都大学学術情報メディアセンター客員教授、名古屋大学名誉教授・客員教授 |
副所長

美濃導彦 - 京都大学学術情報メディアセンター 教授
吉本昌弘 - 京都工芸繊維大学 副学長・大学院工芸科学研究科電気電子工学系教授、ナノ材料・デバイス研究プロジェクトセンター長
牧野圭祐 - 京都市成長産業創造センター センター長／京都大学名誉教授
組織

総務部
地域産業活性化本部
中小企業成長支援部
企業特化型支援部
創業人材育成支援部
京都市ソーシャルイノベーション研究所
研究開発本部
ICT研究開発部
産学公連携事業本部
産学公連携企画部
京都市ライフイノベーション創出支援センター
京都市ライフイノベーション創出支援センター 支所
地域イノベーション戦略推進部
スーパークラスター事業推進部
京都市成長産業創造センター
成長産業創造部
アクセス

JR嵯峨野線丹波口駅から徒歩5分
市バス、京阪京都交通バス「京都リサーチパーク前」、京都バス「五条千本」 下車 徒歩2分
京都駅、地下鉄五条駅、阪急西院駅、阪急大宮駅、京阪清水五条駅からのアクセス→ KRP HP「アクセス ■交通のご案内」
しう (MARETUのアルバム)

しうは、2019年11月17日に発売されたMARETUの2枚目のフルアルバム。
概要

前作から約3年半ぶりのアルバムである。今作は「しう」をはじめ、前作以降に公開・リリースされた楽曲を中心に収録されている。ただし「ドクハク」は収録されていない。現在はMARETUのTwitterでの告知によってzipファイルで無料ダウンロードできることもアナウンスされている。アルバムの形は×印。
収録曲

マジカルドクター
マエガミスト
アイムハイ
ホワイトハッピー
うみなおし
ダーリン
トウテツ
コウカツ
トゥール
ゴキブリの味
しう
ソケット (BSD)

ソケット（英: socket）とは、BSD系UNIXを起源とするAPIであり、C言語によるアプリケーション開発でのプロセス間通信、特にコンピュータネットワークに関するライブラリを構成する。その起源を強調してBSDソケット、バークレーソケットなどとも呼ばれる。
ソケットはネットワーク内の通信エンドポイント（communication endpoint、通信端点）を識別して接続するための概念およびメカニズムである。ソケットとエンドポイントは関連の強い概念であるため、同一視されることもあるが、一般的に「ソケット」と言えば抽象化された通信の概念やAPIを包含するものであり、厳密には別物である。
1983年にリリースされたUNIXオペレーティングシステム (OS) 4.2BSD で初めて API として実装された。ネットワークの抽象化インタフェースとしてのデファクトスタンダードとなっている。伝統的なSocket APIはC言語を対象とするが、他のプログラミング言語でも類似のインタフェースを用意していることが多い。
ソケットの代替となるAPIとして、STREAMSベースの Transport Layer Interface (TLI) がある。しかし、BSDソケットは比較にならないほど普及しており、数多くの実装が存在する。
BSDソケットインタフェース

BSDソケットは、ホスト間の通信や1つのコンピュータ上のプロセス間の通信を可能とする。通信媒体としては様々な入出力機器やデバイスドライバを利用可能だが、その部分はオペレーティングシステムの実装に依存する。このインタフェース実装はTCP/IPを利用する際にはほとんどの場合で必要とされ、インターネットを支える基盤技術の一つとなっている。当初、カリフォルニア大学バークレー校でUNIX向けに開発された。最近の全てのオペレーティングシステムには間違いなくBSDソケットが何らかの形で実装されており、インターネットへの接続の標準インタフェースとなっている。
プログラマの観点から見ると、ソケットインタフェースは3つのレベルでアクセス可能である。最も強力で基本的なレベルは RAW（生）ソケットレベルである。RAWソケットが可能とする通信制御の自由度を必要とするアプリケーションは稀であり、インターネット関連技術の開発でのみ使われるべきとされている。
socketインタフェースは様々なネットワークプロトコルを抽象化している。これらのプロトコル群はprotocol familyとsocket typeに基づいてグループ分けされる。Linuxカーネルでは20を超えるprotocol familyが設定されており、例えばIPv4を指定するAF_INETやUNIXドメインソケットを指定するAF_UNIXがある。全てのprotocol familyは<sys/socket.h>で定義されている。socket typeの例にはSOCK_STREAMやSOCK_DGRAMがある。familyとsocketの組み合わせでトランスポート層プロトコルに相当することが多い。
| row:family/column:type | SOCK_STREAM | SOCK_DGRAM |
| --- | --- | --- |
| AF_INET/AF_INET6 | TCP | UDP |
AF_UNIX: UNIXドメインソケット
ヘッダファイル

BSDソケットにはいくつかのヘッダファイルがある。
TCP

TCP はコネクションの概念を提供する。TCPソケットを生成するには socket() 関数で AF_INET または AF_INET6 と SOCK_STREAM を引数に指定する。
TCP > サーバ

単純なTCPサーバの設定は、以下のように行われる。
TCPソケットを生成（socket()呼び出し）
そのソケットを listen（コネクション確立要求待ち受け）ポートにバインド（bind()呼び出し）。bind() を呼び出す前に、sockaddr_in 構造体を宣言し、その中身をクリアし（bzero() または memset()）、その  sin_family フィールドを AF_INET か AF_INET6 に設定し、sin_port フィールドに listen 対象ポート番号をネットワークバイトオーダで設定する。short int をネットワークバイトオーダに変換するには、htons() 関数を使う。
そのソケットをコネクションの listen に使用するため、listen() を呼び出す。
入ってきたコネクションを accept() 呼び出しで受け付ける。これはコネクションが受信されるまでブロックし、受信したコネクションのソケット記述子を返す。最初の記述子は listen 用記述子のままであり、accept() はそのソケットをクローズするまで何度でも呼び出せる。
遠隔のホストと通信を行う。send()とrecv()、またはwrite()とread()を使用する。
不要になったら、close() を使ってオープンされた各ソケットをクローズする。なお、fork() が行われた場合、各プロセスは見えているソケットを全てクローズしなければならず、複数のプロセスが同じソケットを同時に使ってはならない。
C99 でのサーバー側のソースコード。
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main(void)
{
    // サーバーソケット作成
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    if (sock == -1)
    {
        perror("socket");
        return 1;
    }

    // struct sockaddr_in 作成
    struct sockaddr_in sa = {0};
    sa.sin_family = AF_INET;
    sa.sin_port = htons(1100);
    sa.sin_addr.s_addr = htonl(INADDR_ANY);

    // バインド
    if (bind(sock, (struct sockaddr*) &sa, sizeof(struct sockaddr_in)) == -1)
    {
        perror("bind");
        goto bail;
    }

    // リッスン
    if (listen(sock, 128) == -1)
    {
        perror("listen");
        goto bail;
    }

    while (1)
    {
        // クライアントの接続を待つ
        int fd = accept(sock, NULL, NULL);
        if (fd == -1)
        {
            perror("accept");
            goto bail;
        }

        // 受信
        char buffer[4096];
        int recv_size = read(fd, buffer, sizeof(buffer) - 1);
        if (recv_size == -1)
        {
            perror("read");
            close(fd);
            goto bail;
        }

        // 受信内容を表示
        buffer[recv_size] = '\0';
        printf("message: %s\n", buffer);

        // ソケットのクローズ
        if (close(fd) == -1)
        {
            perror("close");
            goto bail;
        }
    }

bail:
    // エラーが発生した場合の処理
    close(sock);
    return 1;
}
TCP > クライアント

TCPクライアントの設定は、以下のように行われる。
TCPソケットを生成する（socket()呼び出し）
connect() でサーバに接続する。このとき、sockaddr_in 構造体の sin_family フィールドは AF_INET か AF_INET6 とし、sin_port には通信相手が listen しているはずのポート番号をネットワークバイトオーダで設定し、sin_addr にもネットワークバイトオーダで相手の（IPv4 か IPv6 の）アドレスを設定する。
サーバと通信する。send()とrecv()、またはwrite()とread()を使用する。
コネクションの終了と削除処理を close() で行う。なお、fork() が行われた場合、各プロセスは見えているソケットを全てクローズしなければならず、複数のプロセスが同じソケットを同時に使ってはならない。
C99 でのクライアント側のソースコード。
#define _BSD_SOURCE

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define MESSAGE "Hello World!"

int main(void)
{
    // ソケット作成
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    if (sock == -1)
    {
        perror("socket");
        return 1;
    }

    // struct sockaddr_in 作成
    struct sockaddr_in sa = {0};
    sa.sin_family = AF_INET;
    sa.sin_port = htons(1100);

    // localhost の IP アドレスを引く
    struct hostent *hostent = gethostbyname("localhost");
    if (hostent == NULL)
    {
        herror("gethostbyname");
        goto bail;
    }
    memcpy(&sa.sin_addr, hostent->h_addr_list[0], sizeof(sa.sin_addr));

    // 接続
    if (connect(sock, (struct sockaddr*) &sa, sizeof(struct sockaddr_in)) == -1)
    {
        perror("connect");
        goto bail;
    }

    // 送信
    if (write(sock, MESSAGE, strlen(MESSAGE)) == -1)
    {
    	perror("write");
    	goto bail;
    }

    // クローズ
    close(sock);
    return 0;
 
bail:
    // エラーが発生した場合の処理
    close(sock);
    return 1;
}
上記のソースコードは gcc の場合 -std=c99 をつけることによりコンパイル可能であるが、-std=gnu99 を使用した場合は最初から定義されているので #define _BSD_SOURCE はあっても無くてもどちらでも良い。#define _BSD_SOURCE が無いと herror() が使えない。
UDP

UDP はコネクションレスのプロトコルであり、パケットが必ず相手に届くことは保証されない。UDPパケットは順序通りに届くとは限らず、1つのパケットが複数個届くこともありうるし、全く届かないこともある。このようにほとんど何も保証されないため、UDP は TCP に比べてオーバヘッドが小さい。コネクションレスであるとは、2つのホスト間にコネクションやストリームといったものがなく、データが単に個々のパケット（datagram）として届けられることを意味している。
UDP のアドレス空間、すなわちUDPポート番号は、TCPポートとは別物である。
UDP > サーバ

C99 でのサーバ側のソースコード。ポート番号 7654 で UDP サーバを開く。
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
 
int main(void)
{
    // ソケット作成
    int sock = socket(AF_INET, SOCK_DGRAM, 0);
    if (sock == -1)
    {
        perror("socket");
        return 1;
    }

    // struct sockaddr_in 作成
    struct sockaddr_in sa = {0};
    sa.sin_family = AF_INET;
    sa.sin_port = htons(7654);
    sa.sin_addr.s_addr = htonl(INADDR_ANY);

    // バインド
    if (bind(sock, (struct sockaddr *) &sa, sizeof(struct sockaddr_in)) == -1)
    {
        perror("bind");
        goto bail;
    }

    while (1)
    {
        // 受信
        char buffer[4096];
        socklen_t addrlen = sizeof(struct sockaddr_in);
        ssize_t recv_size = recvfrom(sock, (void *) buffer, sizeof(buffer) - 1, 0, (struct sockaddr *) &sa, &addrlen);
        if (recv_size == -1)
        {
            perror("recvfrom");
            goto bail;
        }

        // 受信内容表示
        buffer[recv_size] = '\0';
        printf("datagram: %s\n", buffer);
    }
 
bail:
    // エラーが発生した場合の処理
    close(sock);
    return 1;
}
bind() は、ソケットとアドレス/ポートを結びつける。
最後の無限ループは recvfrom() を使ってポート番号 7654 からのUDPパケットを受信する。引数は以下の通り。
ソケット
バッファへのポインタ
バッファの大きさ
フラグ（read などの他のソケット受信関数と同じ）
アドレス構造体
アドレス構造体の大きさ
UDP > クライアント

C99 でのクライアント側のソースコード。ポート 7654、アドレス 127.0.0.1 に "Hello World!" という内容の UDP パケットを送る。
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define MESSAGE "Hello World!"

int main(void)
{
    // ソケット作成
    int sock = socket(AF_INET, SOCK_DGRAM, 0);
    if (sock == -1)
    {
        perror("socket");
        return 1;
    }

    // struct sockaddr_in 作成
    struct sockaddr_in sa = {0};
    sa.sin_family = AF_INET;
    sa.sin_port = htons(7654);
    sa.sin_addr.s_addr = inet_addr("127.0.0.1");

    // 送信
    int bytes_sent = sendto(sock, MESSAGE, strlen(MESSAGE), 0, (struct sockaddr*) &sa, sizeof(struct sockaddr_in));
    if (bytes_sent == -1)
    {
        perror("sendto");
        goto bail;
    }

    // クローズ
    close(sock);
    return 0;

bail:
    // エラーが発生した場合の処理
    close(sock);
    return 1;
}
UNIXドメインソケット

→詳細は「UNIXドメインソケット」を参照
IP の場合は IP アドレス＋ポート番号で接続先を指定するのに対して、UNIXドメインソケットの場合はファイルパスで指定する。
関数 > socket()

socket() は通信の一方の終端を作成し、それを表すファイル記述子を返す。socket() には以下の3つの引数がある。
domain - 生成するソケットのプロトコルファミリを指定する。
AF_INET - IPv4
AF_INET6 - IPv6
AF_UNIX - UNIXドメインソケット
type - ソケットのタイプ指定。
SOCK_STREAM - 信頼性のあるストリーム指向サービス（TCPに対応）
SOCK_DGRAM - データグラムサービス（UDPに対応）
SOCK_SEQPACKET - SOCK_STREAMとほぼ同じだが、受信したパケットを読み出す際にパケット全体を読み出さないと、残りを破棄する。
SOCK_RAW - IPレベルのプロトコル処理をユーザー側で用意するときに使用
protocol - 通常 0 を指定し、デフォルトの物が選ばれる。トランスポート層のプロトコルは、domain と type で指定されるが（TCPの場合、AF_INET または AF_INET6 と SOCK_STREAM、UDPの場合、同様の AF_ 値と SOCK_DGRAM）、明示的に指定することも可能で、その値は <netinet/in.h> に定義されている。
エラーが発生すると -1 を返す。そうでない場合、新たに確保された記述子を表す整数を返す。
#include <sys/types.h>
#include <sys/socket.h>
int socket(int domain, int type, int protocol);
関数 > gethostbyname() と gethostbyaddr()

gethostbyname() と gethostbyaddr() は名前やアドレスで指定されたインターネット上のホストを表す struct hostent というデータ構造へのポインタを返す。その中には、ネームサーバから得られた情報、/etc/hosts ファイルから得られた情報などが格納されている。ローカルにネームサーバが動作していない場合、/etc/hosts ファイルを参照する。以下の引数がある。
name - ホスト名を指定。例えば "www.wikipedia.org"
addr - in_addr 構造体へのポインタ。中身としてホストのアドレスを指定。
len - addr の長さをバイト数で指定。
type - アドレスのドメイン型を指定。例えば、AF_INET
エラーが発生するとNULLポインタを返し、h_errno を見れば詳しいエラーの原因（再試行すべきか否か）がわかる。そうでない場合、有効な struct hostent * が返される。
struct hostent *gethostbyname(const char *name);
struct hostent *gethostbyaddr(const void *addr, int len, int type);
関数 > connect()

connect() はコネクションの確立に成功すると 0 を返し、エラーが発生すると -1 を返す。
コネクションレスのソケットの場合（User Datagram Protocol）、connect() は送受信の相手を指定するのに使われ、send() と recv() をコネクションレスのソケットで使えるようになる。
#include <sys/types.h>
#include <sys/socket.h>
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
関数 > bind()

bind() はソケットにアドレスを設定する。socket() で生成された時点では、ソケットはアドレスファミリは指定されているが、アドレスは設定されていない。ソケットは、コネクションを受け付ける前にバインド（アドレス設定）される必要がある。以下の引数がある。
sockfd - バインドすべきソケットの記述子
addr - バインドすべきアドレスを表す sockaddr 構造体へのポインタ
addrlen - sockaddr 構造体の大きさ
成功すると 0 を返し、エラーが発生すると -1 を返す。
#include <sys/types.h>
#include <sys/socket.h>
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
関数 > listen()

listen() はバインドされたソケットでコネクション確立要求を待ち受ける。SOCK_STREAM または SOCK_SEQPACKET の場合のみ有効。以下の引数がある。
sockfd - ソケット記述子
backlog - ある時点でペンディングにできる（キューイングできる）最大コネクション数。一般にOSが上限を設けている。
コネクションは accept() されるとデキューされる。成功すると 0 を返す。エラーが発生すると -1 を返す。
#include <sys/socket.h>
int listen(int sockfd, int backlog);
関数 > accept()

accept() は、リモートホストからのコネクション確立要求を受け付ける。以下の引数がある。
sockfd - listen していたソケットの記述子
addr - クライアントのアドレス情報を accept() の中で格納するための sockaddr 構造体へのポインタ
addrlen - addr が指す sockaddr 構造体の大きさを格納する socklen_t へのポインタ。accept() から戻ったとき、実際に格納されたデータ構造のサイズに更新されている。
コネクションが確立された場合、それに対応したソケット記述子を返す。エラーが発生すると -1 を返す。
#include <sys/types.h>
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
ブロッキングとノンブロッキング

BSDソケットは、ブロッキングとノンブロッキングという2つのモードを持つ。ブロッキング・ソケットは、指定されたデータを全て送受信し終わるまで呼び出したライブラリ関数から戻ってこない。そのため、プログラムは決して届かないデータを待って動けなくなる可能性がある。これは、ソケットで listen を続けたい場合などに困る。
ブロッキングかノンブロッキングかを指定するには、fcntl() か ioctl() 関数を使う。
注意点

socket() で確保されたリソースは close() を使うまで解放されない。これは、connect() が成功するまで再試行を繰り返すような実装で注意が必要となる。socket() を呼び出したら必ず対応する close() を呼び出す必要がある。close を使うには <unistd.h> をインクルードする必要がある。
土井正三郎

土井 正三郎（どい しょうざぶろう、1907年（明治40年）12月23日 - 1992年12月18日）は、日本の経営者。三井信託銀行社長を務めた。
経歴

鳥取県米子市出身。土井親男の三男。生家は米子東倉吉町、鉄砲火薬の土井親男商店。
1929年に青山学院高等部を卒業し、同年に三井信託銀行に入行。1958年5月に取締役に就任し、1967年5月に副社長を経て、1968年11月には社長に就任。1971年5月に会長に就任し、1976年6月には相談役に就任。
1973年9月に藍綬褒章を受章し、1979年4月に勲三等旭日中綬章を受章。
1992年12月18日に急性心筋梗塞のために死去。84歳没。
ビジーウェイト

ビジーウェイト（英: busy waiting）とは、プロセスが条件が成り立つかどうかを定期的にチェックする手法の一種。例えば、キーボードからの入力を待ったり、ロックが獲得できるのを待ったりするのに使われる。ある時間だけ遅延させて何かを実行するのに使うこともある。
素朴な実装手法とその問題点

最も単純な実装は「何もしない (nop : No OPerationの略)」処理を繰り返し実行することにより、一定の時間を経過させるという方法になる。CPUはnop命令に出会うとCPU固有の一定時間「なにもしない」ため、実行するnop命令の回数を調整することで狙った時間を経過させることができる。一般にnop命令の繰り返し実行のためにループ構造を使用し、ループの繰り返し数によってnop命令の実行回数を指定する。
しかし、この方法では、CPUの処理速度が異なることによってnop命令1つが消費する時間が異なる場合、ある回数のループによって経過させる時間は変化してしまう。特にデバイスとの入出力処理には、デバイスとのコマンド送受信やデータ処理のタイミングが重要であることがあり、素朴なビジーウェイトをタイミング調整に使用していると、動作が不安定になることもある。速度（クロック周波数）の異なる互換CPUをサポートしたい場合は、プログラムの開始時にnopを用いたループの実効速度を計測し、ビジーウェイト部分で使用する適切なループ回数を計算してセットする等の対処法もあるが、これはプログラム実行中にクロック周波数が常に同じ値に固定されていることを前提としており、負荷に応じて動的にクロック周波数が変動するようなCPUには対応できない。
SMPシステム向けのオペレーティングシステム内のスピンロックの実装などのような特定の状況下において、ビジーウェイトは有効かつ実用的な手法である。しかし、一般にはビジーウェイトはCPU時間を何もさせずに浪費するという観点から推奨される方法ではない。CPU時間を費やして待つ時間があれば、他のスレッドを動作させるほうが効率的である。
C言語でのコード例

以下のPOSIXスレッドライブラリを使ったC言語コードでは、複数のスレッドがグローバル変数によるフラグを共有している。1番目のスレッドはビジーウェイトでフラグの値の変化を待っている。
#include <stdatomic.h>
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

/* 全関数から見えるグローバルフラグ変数 */
atomic_int g_flag;

/* スレッド#1はフラグが偽 (0) になることをスピンして待つ */
static void *thread_func1(void*) {
    while (g_flag) {
        /* 何もしない - 単にチェックしながら回り続ける */
    } 
    printf("Thread#1 received notification: value of flag has been changed to %d.\n", g_flag);

    return NULL;
}

/* スレッド#2は一定時間待機した後にフラグを偽 (0) にする */
static void *thread_func2(void*) {
    sleep(60); /* 60秒間スリープ */
    g_flag = 0;
    printf("Thread#2 changed the value of flag to %d.\n", g_flag);

    return NULL;
}

int main(void) {
    int ret_code;
    pthread_t t1, t2;
    g_flag = 1; /* フラグを真にする */

    ret_code = pthread_create(&t1, NULL, thread_func1, NULL);
    if (ret_code != 0) {
        printf("Failed to create pthread #1.\n");
        return -1;
    }

    ret_code = pthread_create(&t2, NULL, thread_func2, NULL);
    if (ret_code != 0) {
        printf("Failed to create pthread #2.\n");
        return -1;
    }

    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    printf("All pthreads finished.\n");
    return 0;
}
ccコマンドの実態としてGCCまたはClangが利用可能なUNIX系システムでは、次のように上記コードをコンパイルすることができる:
$ cc -std=c11 spinlock.c -pthread
なお、C言語およびC++におけるvolatileキーワードはコンパイラ最適化を抑止するための修飾子であり、効果は処理系に依存する。C/C++の規格でスレッドが標準化されていなかった時代では、スレッド間で共有するフラグ変数にvolatileを指定することで、レジスタキャッシュではなく必ずメモリから値を読み出すように最適化を抑止する効果が期待されることから慣習的に使われていたが、本来はスレッドの同期目的で使ってはならない。フラグ変数の操作をミューテックス (mutex) によるクリティカルセクションで保護して明示的に同期したり、条件変数 (condition variable) を使ったり、上記コード例のようにC11やC++11規格以降のアトミック変数を使ったりするべきである。
一方、JavaあるいはC#のような後発のプログラミング言語では、最初からスレッドが標準化されて言語仕様に組み込まれており、限定された範囲でvolatileキーワードを軽量な同期プリミティブの実装に利用することが可能である。
CPU の利用状況

上記のコードの中で、2番目のスレッドは直ちに60秒間スリープする。その間、最初のスレッドは、2番目のスレッドがフラグの値を変更したかどうかを繰り返しチェックする。
UNIX系オペレーティングシステムでは、top や uptime といったユーティリティを使用してこのプログラムのCPU利用状況を知ることができる。プログラムを以下のように実行する:
$ uptime; ./a.out ; uptime
13:25:47 up 53 days, 23:50,  4 users,  load average: 0.00, 0.00, 0.00
Thread#2 changed the value of flag to 0.
Thread#1 received notification: value of flag has been changed to 0.
All pthreads finished.
13:26:47 up 53 days, 23:51,  4 users,  load average: 0.75, 0.21, 0.07
もちろん、システムによって表示される値は微妙に異なるだろう。しかし重要な点はプログラム実行前にロードアベレージ（システム負荷平均値）が 0.00 だった点である。プログラムを実行すると最近一分間のロードアベレージは 0.75 までに達した。（訳注：ロードアベレージの計算方法は様々だが、少なくとも 1.00 になるとプロセッサ1個が100%動作していることを示す。）
ビジーウェイトの代替手法

代替手法としてシグナルを利用する方法がある。多くのオペレーティングシステムやスレッドライブラリには、1番目のスレッドをスリープさせておいて2番目のスレッドがフラグの値を変更したときにシグナルでそれを通知する手段を提供している。この技法をイベント駆動型プログラミングと呼び、CPU時間を消費しないため、効率がよい。
ビジーウェイト自体も、何らかの遅延関数を使ってより効率的にすることができる。遅延関数はスレッドを指定された時間だけスリープさせるもので、その間CPU時間を消費することがなくなる。このループが非常に簡単なチェックをするだけなら、ほとんどの時間をスリープしているようにできるのでCPU時間の浪費を大きく減らすことになるが、ある程度のCPU時間は消費してしまう。
ビジーウェイトが適している状況

低レベルのハードウェアドライバのプログラミングでは、ビジーウェイトが実際上望ましいこともある。あらゆるデバイスに割り込みによる通知機能を実装することは現実的ではない（特にアクセスがほとんど発生しないデバイス）。場合によっては制御データをデバイスに書き込んで、何らかのデータをそのデバイスから読み出すタイプのアクセス法を採用するデバイスもあり、その際の読み出しは場合によっては数十クロックサイクル待たなければならない（例えばリアルタイムクロック）。プログラマはオペレーティングシステムの遅延関数を呼び出すこともできるが、単に関数呼び出しをするだけで待つべきサイクル数を超える可能性が高い。このような場合、ビジーウェイト方式でデバイスのステータス変化をチェックし続けるのが一般的である。このような場合に遅延関数を呼ぶことは、関数呼び出しのオーバヘッドとスレッド切り替えのためにCPU時間を無駄にするだけだろう。
フォンシェーディング

フォンシェーディング（英: Phong shading）は、3次元コンピュータグラフィックスにおける陰影計算の補間技法である。フォン補間と呼ばれることもある。ラスタライズされたポリゴン群をまたいだ法線ベクトルの補間によってピクセルの色を推測する技法であり、「ピクセル単位照明」(per-pixel lighting) を実現するための補間技法として利用される。グーローシェーディングやフラットシェーディングなどの他の補間技法との対比で、これを「フォンシェーディング」と呼ぶ。
この技法はユタ大学のブイ・トゥオン・フォン（英語版）が考案したもので、1973年の博士論文で発表した。また、フォンシェーディングと同時に、フォンはフォン反射モデル（フォン照明モデル）を提唱した。フォン反射モデル自体は、フォンシェーディングだけでなくグーローシェーディングなど他の補間技法とも組み合わせて使うことがある。フォンシェーディングもまた、フォン反射モデル以外の反射モデルと組み合わせて使うこともできる。
概要

フォンシェーディングはグーローシェーディングより改良されており、滑らかな表面のシェーディングに関して、よりよい近似を提供する。フォンシェーディングは法線ベクトルが連続的に変化すると見なす。フォン補間手法は、フォン反射モデルのように小さい鏡面ハイライトを持つ反射モデルに適用するとき、グーローシェーディングよりも良い結果をもたらす。
グーローシェーディングの大きな問題は鏡面ハイライトが大きなポリゴンの真ん中あたりにあるときに顕著となる。グーローシェーディングではポリゴンの頂点の色を計算し、頂点間を全て補間するため、そのようなハイライトは見えなくなる。フォンシェーディングではこの問題に対処できる。
グーローシェーディングとは異なり、フォンシェーディングではポリゴンの頂点の法線ベクトルからポリゴン内の表面の法線ベクトルを線形補間で求める。シーン上の各ピクセルについてそのようにして法線ベクトルを求め、それぞれに反射モデルを適用してピクセルの色を求める。ピクセル毎に反射モデルの計算をするため、フォンシェーディングはグーローシェーディングよりも計算量が大きくなる。
リアルタイム処理系

リアルタイム処理系向けの3DCG APIのひとつであるDirect3Dには、固定機能シェーダーによる陰影モードD3DSHADEMODEのひとつとしてD3DSHADE_PHONGが用意されていたが、実装・サポートされることはなかった。
プログラマブルシェーダーをサポートするハードウェアでは、ピクセルシェーダーもしくはフラグメントシェーダーにより実装されたフォンシェーディングを実行することができる。
最近[いつ?]のハードウェアには、ピクセルシェーダーやフラグメントシェーダーを使ってこのアルゴリズムの派生を実装しているものもある[要出典]。これは、法線ベクトルを各ポリゴンの2次色として符号化し、ラスタライザにそれをグーローシェーディングで補間させ、ピクセルシェーダーがそれを法線ベクトルとして解釈して各ピクセルの照明計算を行うという方法である。
フォン反射モデル

→詳細は「Phongの反射モデル」を参照
フォン反射は局所的照明 (local illumination) の経験的モデルである。粗い表面のランバート反射と滑らかな表面の鏡面反射を組み合わせて物体表面の反射を表している。これは、滑らかな表面では小さく強い鏡面ハイライトが見られ、鈍い表面ではハイライト部分が大きく徐々に弱まっていくという、フォン自身の定式化されていない観測に基づくものである。この反射モデルには環境光としてのアンビエント項 (ambient term) もあり、シーン全体の弱い散乱光を考慮している。
フォンシェーディング補間の例
フォン方程式の視覚化。照明は白色光で、アンビエント色と拡散反射色は共に青、鏡面反射色は白である。表面に当たった光はほとんど反射されているが、ハイライト部分は非常に狭い。拡散成分の強さは表面の角度によって変化し、アンビエント成分は一様（角度とは独立）である。