Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/
関連リンクは>>2-10辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port26
http://hibari.2ch.net/test/read.cgi/tech/1269343909/
関連スレ
ネットワークプログラミング雑談
http://hibari.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://hibari.2ch.net/test/read.cgi/tech/1086238859/
Port26 ttp://hibari.2ch.net/test/read.cgi/tech/1269343909/
Port25 ttp://pc12.2ch.net/test/read.cgi/tech/1255459388/
Port24 ttp://pc12.2ch.net/test/read.cgi/tech/1246895188/
Port23 ttp://pc12.2ch.net/test/read.cgi/tech/1230466044/
Port22 ttp://pc11.2ch.net/test/read.cgi/tech/1222603744/
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/
Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/
Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/
Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/
Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/
Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/
Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/
Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/
Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/
Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/
Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/
Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/
Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/
Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 http://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 http://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 http://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 http://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 http://pc.2ch.net/tech/kako/970/970344582.html
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
そのソースコード
http://www.unpbook.com/src.html
詳解TCP/IP〈Vol.1〉プロトコル
http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
詳解TCP/IP〈Vol.2〉実装
http://www.amazon.co.jp/exec/obidos/ASIN/4894714957/
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
http://www.amazon.co.jp/exec/obidos/ASIN/4894716674/
TCP/IPによるネットワーク構築
〈Vol.1〉原理・プロトコル・アーキテクチャ
http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/
〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
Linux/POSIXソケットバージョン
http://www.amazon.co.jp/exec/obidos/ASIN/4320120841/
Windowsソケットバージョン
http://www.amazon.co.jp/exec/obidos/ASIN/4320029992/
http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
http://www.amazon.co.jp/exec/obidos/ASIN/4894715414/
WinSock2.0プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/
猫でもわかるネットワークプログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4797323604/
IPv6ネットワークプログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756142362/
Visual Basicではじめるネットワークプログラミング超入門
http://www.amazon.co.jp/exec/obidos/ASIN/4839917523/
★規格
RFC 日本語版リスト
http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
JPNIC RFC関連リンク集
http://rfc-jp.nic.ad.jp/link/
RFC Editor
http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
http://www.freesoft.org/CIE/RFC/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616
IANA Well known port numbers
http://www.iana.org/assignments/port-numbers
C10K ヘヴィーロードサーバ
http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
http://www.whitefang.com/rin/
Java で packet capture
http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
http://www.faqs.org/rfcs/rfc1750.html
BoostSocket
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
The Code Project - Internet & Network programming
http://www.codeproject.com/internet/
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
http://X68000.q-e-d.net/~68user/net/
ethereal - http://www.ethereal.com/
Wireshark - http://www.wireshark.org/
tcpdump - http://www.tcpdump.org/
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
WinPcap - http://www.winpcap.org/
pathchar - ftp://ftp.ee.lbl.gov/pathchar/
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/
libevent - http://www.monkey.org/~provos/libevent/
★プロトコル
TTCP
http://www.sean.de/Solaris/ttcp.html
http://www.kohala.com/start/ttcp.html
UDP Hole Punching
http://homepage3.nifty.com/toremoro/p2p/firewall.html
★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/
http://www.geocities.jp/bruce_teller/security/garakuta.htm
これどういう意味？
WSAGetLastErrorって連続で呼び出したら、エラーコードの情報が
リセットされることってないよね？
ちなみに0が返ってくるのは、クライアント側のウィンドウを強制的に
終了させた時です。
そのときにWSAGETSELECTERRORでエラーになったので、
WSAGetLastErrorでエラーコード取得してみたら0だったんです。
while(1) {
recv();
すこし重たい処理;
}
とするとrecvのデータが欠落(跳んでしまう)してしまうみたいなんですが、どう対処したらいんでしょうか
考えたのは
buff格納キューテーブル
thread1 {
while(1) {
recv();
buffをキューテーブルに格納
｝
｝
thread2{
while(1){
キューテーブルを参照、処理
対象データを取り除く
}
}
という素人案ですが、格納にどれくらい負荷が掛かるかも心配で、
何かいい案はないでしょうか？よろしくお願いします
connect関数を使ったのですが必ずエラーになります。
WSAEWOULDBLOCKのエラーが返ってきます。
これは非同期処理においては当たり前のことなのでしょうか？
もしそうなら、SELECT等やタイムアウト時間を自分で設定するしかないのでしょうか？
これは結局同期処理になってる気がするのですが、CONNECTのときは仕方ないのでしょうか？
本来はブロッキングする処理だけどノンブロッキングモードだからブロックせずに制御を返したよ（もちろんまだ完了してないよ）
っていう意味だから、あなたの望む結果じゃないのでしょうか？
それともノンブロッキングモードを誤解しているのでしょうか？
単に WSAAsyncSelect の FD_CONNECT の存在に気づいてないだけでしょうか？
yes
状況が分からないが
connect関数はコール後すぐに制御を返すが、実際にはまだ接続が完了していない。
その状態であることを知らせるのがWSAEWOULDBLOCKであり、
接続が完了したことを通知するのがFD_CONNECT。
connect関数コール後から接続完了（CONNECT）まで何も処理することがないなら一見するとブロッキングモードと同等になる。
しかし、それらの処理がメインスレッド上で行われている場合、ブロッキングするconnect関数コールは、他のWindowsメッセージの処理すらされなくなる。
本当にありがとうございました。
FD_CONNECTを待とうと思ったんですが、
色々面倒だったので、select使うことにしました。
メインスレッドで実行しますが、接続時なんで多少ブロックされてもいいと判断しました。
select()の待ち時間を0秒にしてもグッとブロックされたりしますか？
それともselect()を使う限りブロックしてしまうものなのでしょうか？
送信側と受信側では同じサイズと間隔で下のように送受信しています
for(i=0;i<j;i++)
send(sock,&buf[l],k);
l=l+197;
Sleep(16);
１回のループに196byteなら問題なく送信できるのですが、197にするとエラー（WSAEFAULT）が
発生します。
これは秒間12KBの送受信になるのですが
同じ１台のパソコンでapacheを起動し画像を送受信すると重い画像でも表示できます
原因が思いつく方がいましたらご教授下さい
お前のバグ。
WSAEFAULTは&buf[l]が有効なメモリアドレスをさしていない場合に出力される。
原因はサーバ側でrecvのbufの使い方が間違ってました
recvは必ず指定したサイズを受信するわけではないので
不便だと思い下のような関数を作ってたのですが
おそらくはcのアドレスを直接渡したのが原因か
またはcのアドレスをサイズ分移動させた後のアドレスと
固定のサイズの4096が一致しないのが原因かと思います
正しい原因は調べてないですが、改善例のように修正したら
問題なく動作するようになりました。
int recv2(SOCKET s,char buf[],int len){
char *c=buf;
char wrk[4096];
while(1){
i=recv(s,c,4096,0);駄目な例
i=recv(s,wrk,4096,0);改善例
memcpy(c,wrk,i);改善例
if(i==SOCKET_ERROR){
shutdown(s,2);
closesocket(s);
return 0;
}
c=c+i;
}
len も読み込んだバイト数分減らしたうえで recv に渡す大きさを len に
送信側と受信側では同じサイズと間隔で送受信しています
送受信するサイズは4MBで、送信側は４ＭＢ送信できてますが
受信側は4MB受信しないで最後のrecvが0を返して終了します。
受信側でデータが無くなることは実際ありえるのでしょうか？
ちなみに毎回決まったサイズ受信して終了します。
＞送信側は４ＭＢ送信できてますが
ちゃんと戻り値を確認してのこと？
sendの戻り値は確認しています。
普通どれくらい待つのでしょうか？
recvが最後に0を返しても送信サイズと受信サイズが一致しないとループし続けるように
コーディングしましたが、１分ぐらい延々とrecvが0を返し続けました。
途中のデータが欠損しているようです。
最後に特定の文字列を送信してそれは受信できていました。
最初のデータを送信する前に１秒Sleepすると問題なく送受信できました。
なんか根本的に間違っていると思う。
やっているのは「非同期通信」なんだろ？
その場合、情報が常に必ず届くという保証がwinsock自体にない。
だから、届かなくてもいいような仕組みを持った通信経路を設計する。
これには色々ある。今の考え方では、すぐに行き詰まると思われ。
申し訳ない
同期通信の間違いでした。
TCP/IP自体データが保障されていると思ってたんだけど
違うのでしょうか？
同期通信なら、保証されるが、それはバグがない場合だ。
何かがバグってるな。
>>1のリンクのサイトや本を見てからにしてください
TCPなのかUDPなのか書け。
＃UDPな悪寒。
メッセージ境界が保証されていないTCPで、メッセージ境界が保存されて
いると仮定してプログラミングしてるんだろ。
ただSOCKET_ERRORかどうかしか見てなくて、実際に受信バイト数までは確認していないってことか？
if (recv(sock, buff, BUFF_SIZE, 0) == -1) {
/* エラー処理 */
}
/* BUFF_SIZE 受信したつもりになりきって buff の処理 */
TCPです
UDPは信頼性がなさそうなので
sendの戻り値でどうやって受信バイト数を取得すんだよ。
で、
n=send(sock,buff, BUFF_SIZE, 0);
n=recv(sock, buff, BUFF_SIZE, 0);
いずれもBUFF_SIZEまで送信受信できているとは限らない。
n がSOCKET_ERRORではない場合、n は実際に送信受信したバイト数になっているが、
その n の値もしっかり反映しているの？
それと、SOCKET_ERROR の場合は終了しているようなので関係ないが
送信受信において SOCKET_ERRORが戻ってきた場合のWSAGetLastError() の戻り値も確認する。
WSAEWOULDBLOCK が戻ってきてれば終了するのではなく、またループに戻るようにする。
sendとrecvの戻り値は確認しています。
戻り値が0より大きい場合にその戻り値をlenとしてmemcpyするように
しています。
WSAEWOULDBLOCKについては知りませんでした。
ご指摘ありがとうございます。
データを適当なバイト数送るとします。
受信側がそのうち200バイトしか受信できなかったとします。
受信できるまでrecvループしようとしましたが、その間はそこで処理が
止まってしまうので、ウィンドウが固まってしまいます。
なので、一度だけ受信した後、一旦受信処理ルーチンを抜け、
また再度FD_READメッセージを待ちます。
そこで受信できなかった分を受信し、先ほど受信したデータの後ろにMEMCPYでデータを
くっつけようとします
そのためには先ほど受信したデータのバイト数を記録しておく必要があると思います。
さらに、相手は何バイトデータを送ってくるかわかりません。
この場合、まずデータが何バイト送ってきたのかを記録しとくところまではできますが、
何バイトまで受信すればよいのかわかりません。
単純にrecvがsocket_errorを返し、WSAEWOULDBLOCKを返したときが受信データは全て
受信し終わったと判断してよいでしょうか。
それをヘッダと言うことが多い
どういう形の書式にするかとかを決めるのがぷろところろろｒ
その分だけ受信するってことですか。
いろんなプロトコルがありますが、データサイズだけわかればなんとかなりそうなので、
自分独自のヘッダでも構わないんですよね？
ストリーム故、同じ思考にいきつくと思うが （fgets はそうでもないか）
データ長があらかじめ判らないときには
データ末尾に終了符号をつけることもある
ダサい設計だけど、HTTP1.0のようにデータの最後まで送ったら
ソケットを閉じるという方法もある。
亀レスだが、非同期通信に到達性を保証する事は出来ないと思うのだが。
その点について俺が間違っているの教えてくれ。
まず第一に、非同期通信経路上位でのプロトコルによる同期は除いてくれ。
単純に非同期通信経路で、受信側がいつまでたってもデーターはこなかったとしよう。
その場合いつかはタイムアイトになり情報が所か無かったとしよう。
送信側は送信しているので、それが届いたかどうかは感知できない。
この場合どう考えても、情報の到達性を保証する事は出来ない。
ではないのか？
何を勘違いしてるのか分からないけど、あの文脈では同期／非同期
はAPIのモードの話で
同期：ブロッキング
非同期：ノン・ブロッキング
でしょ？
それともブロッキングのsend成功＝到達とでも思ってるとか？
それを非同期の代名詞にして話す事自体がっかりだよ。あきれた
なるのかな？
昔の非同期モデム使ったPPP回線でも（TCPの意味での）到達性は保証
されているのだが。
表現するのはごく普通に行われているよ。
なにせWinSockのAPI名がWSAAsyncSelectとかだし。
それMSの表現が馬鹿なだけw
だけど、 TCP 使って非同期な通信系ってのはどうゆう意味か説明してほしいな >59
非同期型API
がごっちゃになってる？
まあ、あまり大声で言わない方がいいと思うがwww。
それに、がっかりしたのも事実だし。言葉の定義はそれでもいいんじゃい。
通信相手との同期を取らない点では一種の非同期通信といえるが、いわゆる非同期通信が
単に通信相手からの返事を待たない(同期を取らない)というニュアンスであるのに対し、
ノンブロッキング通信では主に、通信処理の完了を待つことによって他の処理の進行を妨げな
いことを表わしている。
TCP ってのは、 end-end 閉じてないとだめなプロトコルなのね
で、少なくとも、
syn -> syn/ack -> ack
で、コネクションつくって、 こんなやりとりするでしょ？
[data]/ack <-> [data]/ack
この状態が、成立してる限りにおいては同期処理系なのよ
つか、state-fullなプロトコルってのは、どこかで同期する必要があるのは当たり前
もっと上のところでやるのはあんたらの勝手だけど、どの部分指して言ってるの?
ってのが 62 の主旨
TCPの実際の動作がわかってない感じだから、どう言っていいのやら...
たとえば、HTTP/1.1は非同期。
レスポンスが返ってくる前に、リクエストを投げることができる。非同期だろ。
発端の>>22の「非同期」はWinsockの非同期系APIを指しているのだろうけど。
その説明書いた人良く分かってない感じ。
socket APIのブロッキングモードのsendは送信バッファに空きが
出来れば復帰するのであって、通信処理が完了するかどうかとは
関係ない。
非同期通信をして、文字だけのやりとりはできるようになりました。
ですが、ユーザごとに名前をつけれてません。
名前付けたいんですが、名前のデータは文字のバッファに含めて送信すべきでしょうか？
それとも名前は名前だけで送ったあとに、後から文字のバッファを送るほうが都合がいいでしょうか？
今はクライアント→サーバにメッセージを送ったら、
サーバから、サーバに接続しているクライアント全てにそのメッセージを送信し、
リアルタイムチャットを作ろうとしているところです。
じゃ、そこまできちっとしたら、ブロッキングモードの通信も非同期だなwwwww
腹抱えて笑うぜwwwwwwwwwwwwwwwww
非同期で笑え
addr は INET_ANY で create & bind -- (*)
WSAAsyncSelect FD_READ でパケ待ち
パケ到着なFD_READをきっかけに recv & 内部処理開始
内部処理後の応答を パケ送信したピアへ戻したい...
(*)のソケットに write ではうまくいかず
recvfromとsendtoを使え
recvfrom の末尾で ピアのアドレス受けとれるし…
>>58 >>62 どっちとも俺の解釈と違う(と思う)。
まだデータが到着してないときにrecvした場合、
データが来るまで関数が返ってこないのがブロッキング。(1)
関数が返ってきて「まだない」と言われるのがノンブロッキング。(2)
データが到着したことがわかった後で、カーネルに「俺のバッファにコピーしる」
と要求したら、コピー完了後に返ってくるのが同期。(3)
コピー完了前に帰ってきて、コピー完了が別に通知されるのが非同期。(4)
と思ってる。
unixしか知らないひとがよく非同期と誤解してるのが(2)
MSが言ってる非同期は(4)
でないかな？
用語の使い方がずれてんだよ、WindowsとUnixは。
今迄画像処理関連のプログラムばかりやってきて
4月からネットワークプログラムの仕事になりそうなんで
異動前に勉強したいんだが
ネットワークプログラムする以前にネットワークに関する知識(スイッOハブの知識、ネットワークの構成・設計、セキュリティetc)が無い
何かオススメの本あったら教えて
recv, send は「非同期I/O」とは呼ばない。
「非同期I/O」は
aio_read, aio_write のこと。
aio_readなんて誰も使ってないだろうけど、
Windowsで言ってる非同期はまさにaio_xxxなんだぜ
わかた
ごちそうさま
良レスだが、自分の解釈とも異なっている。(もちろん>>58,62とも違う)
>>77の例であれば、どちらも同期(という総称的な概念を指す用語)の一種であり、
それらの違いは「データ到着」と「コピー完了」というイベント種別の違いでしかない、いうのが自分の解釈。
ブロッキングは同期(という目的)を実現する手段であり、両者を同列に比較/分類する事は無意味であると思う。
まとめると、>>77の(1)と(2)は同じだが、(3)はブロッキングモードのrecvであり、(4)はノンブロッキングモードの
非同期recvであり、さらに(3')としてノンブロッキングモードの同期recvが加わる。
Unixであれば、read/write/recv/sendは、どれもブロッキングモード/ノンブロッキングモードのどちらでも
操作を実行できる。ただしノンブロッキングモードの場合、データ未着/コピー未完であればアプリ側で定期的に
リトライしなければならないという(性能上の)問題があるため、必然的にブロッキングモードを使わざるをえなかった。
この課題を解決する為に考案(追加)されたのが、aio_read/aio_writeと呼ばれる、いわゆるAIO(非同期I/O)という仕掛け。
ちなみにLinuxのAIO実装の場合、ソケットに対するAIOはサポートされていないから、aio_recv/aio_sendという
システムコールは(まだ)存在していない(はず....)。
お前が正しい
正義はお前にある
つ ttp://www.amazon.co.jp/dp/4274066770
だな。
そのノンブロッキングの同期が一番おいしいのに
そこを飛び越えてしまったのがWinsock2
レスありがとうございます。
スレ違いにも関わらず…助かります。
なんかITProの記事では、v4アドレスが2011年2月に
枯れるとか言ってるんだがホント？
それまでのペースを維持すれば、当然3月くらいまでに無くなるよ。
http://www.geekpage.jp/blog/?id=2010/10/18/1
http://journal.mycom.co.jp/news/2010/11/16/074/index.html
アジア地域だと、本当に再来年あたりから
新規v4は無くなる可能性があるみたいね。
v6Readyはもう必須かもしれない。
Accept-Encoding: gzip
Range: bytes=41318-
として、順次差分をダウンロードしたいのですが
gzip圧縮された差分がgzipのヘッダー情報を含んでいるらしく
レスポンスのContent-Lengthと食い違いが生じてしまいます
この場合の定番の書き方はどうなっているのでしょうか？
それとも差分ダウンロードと圧縮は同時に使用しないものなのでしょうか？
> レスポンスのContent-Lengthと食い違いが生じてしまいます
ダウンロードした圧縮差分を順次つなげていっても
元のgzipファイルにならないという意味です。念のため
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
VBScriptについて必死に話し合うスレ (177)
【PSP】PSPで東方やりたい奴12【弾幕】 (148)
ニートの俺が何か開発して食いつなぐスレ (687)
.netグレープシティコンポーネント (115)
Ruby 初心者スレッド Part 48 (708)
Kinect ハック (937)
--log9.info------------------
■■【懐かし】Ｎゲージ：レア品物語10【珍品】■■ (169)
最も好きなELと嫌いなELを語ろう！ (112)
KATO・TOMIX・マイクロエースを何かに例えると (637)
お金が無い、たがどうしても欲しい物が目の前に (145)
鉄道模型コレクター (103)
国鉄急行型電車を模型で楽しむスレ Part6 (672)
【1/120】太っちょＫＩＮＧ＝ＴＴ９スレ-2-【9mm】 (279)
Ｎゲージで買って損をした製品 (207)
【ウソつき】1/80 16.5mmをHOと偽る【荒らし】 (184)
転売は俺の生きがい (123)
ＴＯＭＩＸで分売パーツにしてほしい物 (336)
【釣掛】地方電鉄の旧型車を楽しむスレ【譲渡車】 (615)
バスコレクションについて語ろうぜ (435)
【松屋銀座】鉄道模型ｼｮｳ part3 【限定】 (191)
鉄道模型地震被害報告スレ 国内史上最大M8.8 (143)
ＰＥＣＯ以外の道床無しレールは消える運命 (135)
--log55.com------------------
【早慶がなんだ】川俣軍司 24【人間根性だ】
2019年9月下旬に発生した山梨県の道志村キャンプ場での7歳女児の行方不明 〜その47〜
2019年9月下旬に発生した山梨県の道志村キャンプ場での7歳女児の行方不明 〜その51〜
2019年9月下旬に発生した山梨県の道志村キャンプ場での7歳女児の行方不明 〜その51〜
【パヨク悲報】若い世代ほど安倍内閣支持、「なんで俺らパヨクは年寄りばっかなんや・・・」 Part2
日本のパクリしかできない朝鮮人、韓国政府がドラえもんそっくりのキャラを制作して大ひんしゅくw
【Jap】ひろゆき「日本の大学生がバカすぎるｗ 大卒の韓国人はみんな英語しゃべれるからねw」
【パヨク悲報】反日種族主義の著者「日韓関係を悪化させたのは日本のパヨク」