サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
夏の料理
s-kita.hatenablog.com
C#でSSL通信を行う。 サーバー証明書の検証も行う。 例として、インターネット上のWebサーバーとSSL通信を行う。 手順は、以下のようになる。 1Webサーバー名からWebサーバーのIPアドレスをDNSでルックアップ 2TcpClientを用いて、Webサーバーの443番ポートに接続する 3SslStreamを生成し、でSSL通信を開始 4SslStream#AuthenticateAsClientメソッドで、サーバー証明書の検証を行う 5HTTPリクエストを送信する 6HTTPレスポンスを受信する PrintCertificateメソッドは、サーバー証明書の内容をコンソールに表示するためのメソッド。 RemoteCertificateValidationCallbackメソッドで、証明書の検証を行なっている。 using System; using System.Net; using
Windows Vistaで追加されたスレッドプールの特徴のひとつとして、従来のQueueUserWorkItem関数ではコールバック関数が終了したことを、スレッド起動側が知ることができなかったのが、新しいスレッドプールでは、コールバック関数の終了を知ることができるようになった、ということがある。 新しいスレッドプールの使い方の手順としたは、おおよそ以下のようになる。 1.CreateThreadpoolWork関数で、スレッドプールの作業アイテムを作成 2.SubmitThreadpoolWork関数で、作業アイテムを割り当てる 3.WaitForThreadpoolWorkCallbacks関数で、作業アイテムの完了を待機する 4.CloseThreadpoolWork関数で、作業アイテムを解放する CreateThreadpoolWork関数のプロトタイプ PTP_WORK WINA
ウィンドウの情報を得るには、GetWindowInfo関数を用いる。 GetWindowInfo関数のプロトタイプは、以下の通り。 BOOL GetWindowInfo( HWND hwnd, PWINDOWINFO pwi ); 第二引数のWINDOWINFO構造体は、WinUser.h にて、以下のように定義されている。 typedef struct tagWINDOWINFO { DWORD cbSize; RECT rcWindow; RECT rcClient; DWORD dwStyle; DWORD dwExStyle; DWORD dwWindowStatus; UINT cxWindowBorders; UINT cyWindowBorders; ATOM atomWindowType; WORD wCreatorVersion; } WINDOWINFO, *PWIND
Windowsのデスクトップ上のウィンドウを検索するには、FindWindowEx関数を使う。 FindWindowExのプロトタイプ HWND FindWindowEx( HWND hwndParent, // 親ウィンドウのハンドル HWND hwndChildAfter, // 子ウィンドウのハンドル LPCTSTR lpszClass, // クラス名 LPCTSTR lpszWindow // ウィンドウ名 ); ウィンドウには親子の関係があり、これらのウィンドウを検索するには、再帰処理などで親子関係を手繰っていく必要がある。第二引数のhwndChidAfterはそれを実現するための引数である。 デスクトップ上のすべてのウィンドウを列挙するサンプルプログラム再帰処理でウィンドウの親子関係を手繰って、デスクトップ上のウィンドウをすべて列挙する #include <Windows.h
セマフォは、複数のプロセス間の同期や、あるプロセス中の複数のスレッド間の同期のために用いられる。 セマフォの種類 1.Posix名前付きセマフォ。PosixのIPC名で識別され、プロセス間あるいはスレッド間の同期に用いる。 Posixメモリベースセマフォ共有メモリに置かれ、プロセス間あるいはスレッド間の同期に用いることが出来る。 System V セマフォカーネル内で管理され、プロセウ間あるいはスレッド間の同期に用いることが出来る。 セマフォの3種類の操作 セマフォの作成(create) 作成時には呼び出し側が初期値を指定する必要がある。 セマフォに対する待機(wait) セマフォ値を検査し、その値がゼロより小さいかまたは等しい場合には待機(ブロック)する。待機中に0より大きな値に変化したら、それを減じる。 このwait操作は、P操作(Pは、オランダ語で試行を意味するproberenの頭文
使用するAPI FindFirstFile FindNextFile FindClose 使用するデータ構造 WIN32_FIND_DATA typedef struct _WIN32_FIND_DATA { DWORD dwFileAttributes; // 属性 FILETIME ftCreateTime; // 作成日時 FILETIME ftLastAccessTime; // 最終アクセス日時 FILETIME ftLastWriteTime; // 最終更新日時 DWORD nFileSizeHigh; // ファイルサイズ(上位32ビット) DWORD nFileSizeLow; // ファイルサイズ(下位32ビット) DWORD dwReserved0; // リパースタグ DWORD dwReserved1; // 予約 TCHAR cFileName[MAX_PATH
Visual C++ 2010でTR1で定義されていた正規表現がstd名前空間に取り込まれて使用できるようになったということで、試してみる。 TR1ということで、使い方はboostとほぼ同じようです。 regex_searchで、正規表現にマッチさせる #include <regex> #include <string> #include <iostream> int main() { std::regex re("[0-9]+"); std::match_results<const char *> results; if (!std::regex_search("xxx123456yyy", results, re, std::regex_constants::match_default)) { return 1; } std::cout << "prefix: " << results
レジストリキーの属性やエントリが変更されたことを検知するためには、RegNotifyChangeKeyValue関数を用いる。 RegNotifyChangeKeyValue関数は、レジストリが変更されたことをアプリケーションに通知してくれる。 RegNotifyChangeKeyValue関数のプロトタイプは、以下のようになっている。 LONG RegNotifyChangeKeyValue( HKEY hKey, // 監視するべきキーのハンドル BOOL bWatchSubtree, // サブキー監視オプション DWORD dwNotifyFilter, // 通知するべき変更 HANDLE hEvent, // 発生させるべきイベントのハンドル BOOL fAsynchronous // 変更の通知方法を示すフラグ ); dwNotifyFilterには、以下の値を組み合わせて通
Win32 API Path Routines Win32 APIでパスを扱うには shlwapi.h に定義されている関数群(Path Routines)を使用する。その際、shlwapi.h をインクルードし、shlwapi.lib をリンクする必要がある。 Path Routinesには、以下のような関数がある。 PathAddBackslashパスの末尾にバックスラッシュ(円マーク)を追加する PathAddExtensionパスの末尾に拡張子を追加する PathBuildRootドライブ番号からルートパスを作る PathCombine2つのパスを結合する PathFileExistsファイルやディレクトリが存在するかを判定する PathFindExtensionパスの中から拡張子の位置を探す PathFindFileNameパスの中からファイル名の位置を探す PathFindNe
ソケットはデフォルトでブロッキング。ソケットに関するシステムコールは、4つに分類できる。 入力操作 read, readv, recv, recvfrom, recvmsg。これらの関数をブロッキングTCPソケットに対して呼び出した際にソケットの受信バッファにデータが存在しない場合、呼び出したプロセスはデータが到着するまでスリープする。 ある量のデータが到着するまで待ちたいときには、MSG_WAITALLフラグを指定する。 非ブロッキングソケットでは、入力操作が即座に終了しない場合、これら関数呼び出しは即座にEWOULDBLOCKエラーを返して終了する。 出力操作 write, writev, send, sendto, sendmsg。TCPソケットではカーネルがアプリケーションのバッファからソケットの送信バッファにデータをコピーする。ブロッキングソケットの送信バッファに空きがない場合、
この度、Visual Studio 2010からC++0xのshared_ptrを使うことができるようになったということで試してみました。 まず、2つのshared_ptrで整数型の配列を参照する例(ソースコードについて、コメントを頂きましたため、修正いたしました。) #include <stdio.h> #include <memory> int main() { const int SIZE = 5; std::tr1::shared_ptr<int> p1(new int[SIZE], [](int* ptr) { delete [] ptr; });//配列型は、delete [] ptr; とメモリを解放する必要がある //std::tr1::shared_ptr<int> p1(new int[SIZE]);//int型の配列を確保 std::tr1::shared_ptr<i
システムの電源状態を取得するには、GetSystemPowerStatus関数を用いる。 GetSystemPowerStatusのプロトタイプ BOOL GetSystemPowerStatus( LPSYSTEM_POWER_STATUS lpSystemPowerStatus ); SYSTEM_POWER_STATUS構造体 typedef struct _SYSTEM_POWER_STATUS { BYTE ACLineStatus; //AC電源状態 BYTE BatteryFlag; //充電状態 BYTE BatteryLifePercent;//電源の残りの割合 BYTE Reserved1;//予約 DWORD BatteryLifeTime;//バッテリーの残り時間(秒) DWORD BatteryFullLifeTime;//フル充電時のバッテリーの寿命(秒)。フル
通常ディレクトリを作成する場合は、CreateDirectory関数を用いるが、この関数では1度に階層化されたディレクトリを作成することができない。 例えば、以下の例ようにCreateDirectory関数で階層化されたディレクトリを作成しようとするとエラーになり、GetLastError関数の戻り値は「3(指定されたパスが見つかりません。)」となる。 例:CreateDirectoryでカレントディレクトリに階層化されたディレクトリを作成する(エラーになる) if (!CreateDirectory(L".\\a\\b\\c\\d\\e\\f", NULL)) {//エラーになる printf("%d\n", GetLastError()); } そこで、階層化されたディレクトリを1度に作成したい場合は、MakeSureDirectoryPathExists関数を用いる。 MakeSur
ディレクトリの変更を監視するの変更を監視するには、ReadDirectoryChangesW関数を用いる。.NET Frameworkでは、System.IO.FileSystemWatcherがこの関数の機能に相当する。 ReadDirectoryChangesWのプロトタイプ BOOL ReadDirectoryChangesW( HANDLE hDirectory, // 監視するディレクトリのハンドル LPVOID lpBuffer, // 読み取った結果を受け取る // バッファへのポインタ DWORD nBufferLength, // lpBuffer の長さ BOOL bWatchSubtree, // ディレクトリまたはディレクトリツリーを // 監視するためのフラグ DWORD dwNotifyFilter, // 監視に使うフィルタ条件 LPDWORD lpBytes
ConnectionConnectionヘッダーフィールドは、2つの役割を持つ 指定したヘッダーフィールドをホップバイホップヘッダーにする Connection: ホップバイホップヘッダーにするヘッダーフィールド名例 Connection: Upgradeクライアントからのリクエスト、サーバーからのレスポンスでConnectionヘッダーフィールドを使うと、指定されたヘッダーフィールド名をホップバイホップヘッダーにする。つまり、プロキシサーバーに対してそれ以上転送しないヘッダーフィールドを指定することができる。 ここに、エンドトゥエンドヘッダーを指定することはできない。 持続的接続の管理 Connection: CloseHTTP/1.1では、持続的接続が既定である。 サーバー側が接続を閉じたい場合、ConnectionヘッダーフィールドにCloseを指定する。 Connection: K
汎用ヘッダーフィールド Cache-ControlCache-Controlヘッダーフィールドは、ディレクティブと呼ばれるコマンドをフィールド値に指定することで、キャッシングの動作を指定する。Cache-Controlヘッダーフィールドのディレクティブはリクエストとレスポンスの両方で使用できる。 キャッシュコントロールリクエストディレクティブ ディレクティブパラメータ説明 max-age必須レスポンスの最大Age値 max-stale省略可能期限切れのレスポンスを受け入れる min-fresh必須指定した時間は新鮮さがあるレスポンスを望む no-cacheなしオリジンサーバーへの強制的な再検証 no-storeなしキャッシュはリクエスト、レスポンスの一部分を保存してはならない no-transformなしプロキシはメディアタイプを変換してはならない only-if-cachedなしキャッシ
あるアルゴリズムを実装しているときに、System.Collections.Generic.Dictionary型のキーの型としてKeyValuePair構造体を指定してAddメソッドやContainsKeyメソッドを実行していたところ、極端にパフォーマンスが悪いと感じたので色々調べてみました。 例としては、ちょうど以下のような感じ。 Dictionary<KeyValuePair<Int32, Int32>, Int32> d = new Dictionary<KeyValuePair<Int32, Int32>, Int32>(); パフォーマンスの比較として、キーの型をInt32型、String型に指定した場合とKeyValuePair型に指定した場合のAddメソッドとContainsKeyメソッドの処理速度を計測しました。コードは以下の通り。 using System; using
ファイルやディレクトリの名前や属性、サイズ、書き込み日時、セキュリティ属性変更の変更を検知する 使用するAPI FindFirstChangeNotification FindNextChangeNotification FindCloseChangeNotification HANDLE FindFirstChangeNotification( LPCTSTR lpPathName, // 監視するディレクトリの名前へのポインタ BOOL bWatchSubtree, // ディレクトリやディレクトリツリーの監視用の // フラグ DWORD dwNotifyFilter // 監視のためのフィルタ条件 ); dwNotifyFilterに設定可能な定数 FILE_NOTIFY_CHANGE_FILE_NAME監視中のディレクトリ、またはサブツリーでファイル名が変更されると、変更通知の待
I/Oの多重化(I/O multiplexing)2つ以上のI/Oに対して、どれかが入出力可能になった場合の通知をカーネルに依頼する機能 I/Oの多重化が用いられる状況クライアントが複数のディスクリプタ(普通はstdinとネットワークソケット)を扱っている時 クラインとが複数のソケットを同時に扱う場合 TCPサーバーが、リスニングソケットを接続済みソケットを同時に扱う場合 サーバーがTCPとUDPの両方を扱っている場合 サーバーが複数のサービスや、複数のプロトコルを扱う場合 I/OモデルブロッキングI/O 非ブロッキングI/O I/Oの多重化 (select, poll) シグナル駆動I/O (SIGIO) 非同期I/O (aio_関数群) ブロッキングI/Oモデル 最も一般的に用いられる。 非ブロッキングI/Oモデル ソケットを非ブロッキングに設定することは、そのソケットに要求したI/O
トランザクションBEGIN COMMIT ROLLBACK SAVEPOINTトランザクションでROLLBACK文ではとトランザクション全体が取り消されたが、セーブポイント機能を使って一部だけ実行を取りけり、トランザクションを継続することができる。 SAVEPOINTは、PostgreSQL 8.0から加わった機能。 SAVEPOINT savepoint_name ROLLBACK [TO SAVEPOINT savepoint_name] RELEASE [SAVEPOINT] savepoint_name モードと隔離レベルトランザクションには、モードと隔離レベルという2つの属性がある。 モードREAD ONLY READ WRITE 隔離レベルREAD UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE これらは、トランザ
Posix.1では、無関係なプロセス間でのメモリ共有を行う方法を2種類提供している。 1.メモリマップファイル(memory-mapped files): ファイルをopenし、結果のファイルディスクリプタをmmapでプロセスのアドレス空間にマップする 共有メモリオブジェクト(shared memory objects): shm_openでIPC名をオープンし、返されたディスクリプタをmmapでプロセスのアドレス空間にマップする shm_open関数、shm_unlink関数Posix共有メモリの使用には、2ステップの処理が必要。 1.名前引数を与えてshm_openを呼び出す 2.mmapを呼び出し、共有メモリを呼び出したプロセスのアドレス空間にマップする shm_openで用いた名前引数は、このメモリを他のプロセスから共有する場合に用いる名前になる。 #include <sys/mm
DeflateStreamクラスを用いてデフレートアルゴリズムによるファイルの圧縮、解凍を行う(ソースコードを改訂しました) using System; using System.Collections.Generic; using System.Text; using System.IO; using System.IO.Compression; class Program { public static void Main() { ///////////////////////////////////////////////////////////////////// //圧縮 String sourceFileName = @"test.txt";//元ファイルの名前 String deflateFileName = @"test.lz";//Deflateで圧縮したファイルの名前
フィールドの制約NOT NULL制約 CHECK制約 UNIQUE制約 PRIMARY KEY制約 外部キー制約 NOT NULL制約指定したフィールドにNULLを設定することを禁止する。 CREATE TABLE mytable ( id serial, name varchar(256) <b>NOT NULL</b> ); CHECK制約制約をフィールドの値に対する任意の式で指定する。 フィールド制約としてもテーブル制約としても記述可能。 CREATE TABLE mytable ( id serial PRIMARY KEY, age int CHECK(age > 0), sex int NOT NULL CHECK(sex=1 OR sex=2) ); UNIQUE制約指定したフィールドで値が同じレコードがあってはいけないという制約。 フィールド制約としてもテーブル制約としても
Introductionメッセージキューは、メッセージのリンク構造と考えることが出来る 各メッセージはレコードであり、各メッセージには送信側が指定した優先度が付いている。 メッセージの書き込みに際しては、そのキューにおいて何らかのプロセスがメッセージの到着を待っていることが要求されない。(パイプと対照的) メッセージキューはパイプと異なり、カーネル持続性(kernel persistence)を持つ。(パイプ、FIFOでは、それらが最後にクローズされる際に、残っているデータは破棄される。) PosixメッセージキューとSystem V メッセージキューの違いPosixメッセージキューからの読み出しは、常に最も高い優先度の最も古いメッセージを返す。System V メッセージキューでは、任意の優先度のメッセージを読み出すことが出来る。 Posixメッセージキューでは、空のキューにメッセージが
このページを最初にブックマークしてみませんか?
『s-kita’s blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く