タグ

ブックマーク / eng-blog.iij.ad.jp (7)

  • ファイル書き込みをするプログラムで気をつけた方がよいこと | IIJ Engineers Blog

    この記事について この記事では、ファイルに書き込みを行うプログラムを実装する時の注意点について説明します。 ファイル書き込みは、プログラミングにおいて比較的よく利用される機能でありながら、実装時に注意していないと、システムクラッシュ(意図しない電源の喪失や OS のクラッシュ等)後にファイル上のデータが整合性を失う可能性、平たく言えば、データが破損する場合があります。 今回の主な内容はトランザクションに関連する事柄で、ご存知の方からすると当たり前と思われることだと思われますが、執筆者がプログラミングの勉強を始めて以降知らない期間が長かったことと、他にもご存知ない方がある程度いらっしゃるのではないかと思ったため、このように記事にさせていただきました。 また、ここで説明する注意点は、クラッシュ後にデータの整合性が重要でない場合は、気を付ける必要がないものであることを先に書いておきます。 先にこ

    ファイル書き込みをするプログラムで気をつけた方がよいこと | IIJ Engineers Blog
  • Docker完全に理解した | IIJ Engineers Blog

    九州支社技術部(九州・中四国事業部)所属。自作パソコン好きで、ハードウェア選定の仕事を与えると喜ぶ。最近は何でもコンテナにしたい教に入信し、コンテナ化の機会を虎視眈々と狙っている。 Docker完全に理解した? 【エンジニア用語解説】 「完全に理解した」 製品を利用をするためのチュートリアルを完了できたという意味。 「なにもわからない」 製品が質的に抱える問題に直面するほど熟知が進んだという意味。 「チョットデキル」 同じ製品を自分でも1から作れるという意味。または開発者人。 — 伊藤 祐策(パソコンの大先生) (@ito_yusaku) September 20, 2018 ということで、Docker完全に理解したので、自分なりの「これからDockerでコンテナを始める時のポイント」をいくつかご紹介したいと思います。 申し遅れましたが、九州支社技術部(九州・中四国事業部)所属のy-m

    Docker完全に理解した | IIJ Engineers Blog
    uokada
    uokada 2022/01/07
  • システムコールを速く漏れなくフックする方法 | IIJ Engineers Blog

    ptrace、Syscall User Dispatch:カーネルが提供している ptrace や Syscall User Dispatch のような機能は、ユーザ空間でシステムコールのフックを実装するために利用できます。ですが、これらを利用すると、元のユーザ空間プログラム内部でのシステムコール呼び出しのコストが大きくなり、結果として、性能が大きく劣化してしまいます。(要件1を満たせない) eBPF :eBPF のようなカーネル内の関数へフックを適用できる仕組みもありますが、eBPF は XDP のような場合を除くと、基的にカーネルの挙動を変更するためには利用できないため、カーネル機能をユーザ空間でエミュレートする、といった用途には適していません。(要件5を満たせない) ライブラリ関数の置き換え:標準ライブラリ(libc 等)は、沢山のシステムコールのラッパーライブラリ関数を実装してお

    システムコールを速く漏れなくフックする方法 | IIJ Engineers Blog
  • QUICをゆっくり解説(14):輻輳制御 | IIJ Engineers Blog

    Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 「フロー制御」の回で説明したように、輻輳制御とは途中のネットワークが溢れないようにするための仕組みです。QUICは、正確なRTT計測や、前回説明した簡潔なロス検知の機能を提供しています。このため輻輳制御としては、パケット欠落や遅延といったシグナルを使うアルゴリズムが利用可能です。RFC9002では、デフォルトの輻輳制御アルゴリズムとしてNewRenoを採用しています。 1990年に現れたRenoは、1995年に出されたアイディアに基づいて改良されNewRenoとなりました。2008年に提案されたCUBICや、2016年に現れたBBRに比べると、NewRenoは古い輻輳制御アルゴリズムです。QUICのデフォルトの輻輳制御に古いNewRe

    QUICをゆっくり解説(14):輻輳制御 | IIJ Engineers Blog
  • QUICをゆっくり解説(3):QUICパケットの構造 | IIJ Engineers Blog

    Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回の説明では、「Initial パケット」や「Version Negotiation パケット」といった用語を未定義で使いました。今回は、こういった「パケット」や「フレーム」が、どのような構造を持っているかについて説明します。 古典的なパケット IP、UDP、およびTCPでデータをやり取りする基単位は、すべて「ヘッダ+ペイロード」という構造を持っています。このヘッダ+ペイロードという単位は、それぞれ以下のように呼ぶのが慣習です。 IP – パケット UDP – データグラム TCP – セグメント すべてパケットと呼んでも間違いではありません。UDPの場合、IPペイロードが「UDPデータグラム(UDPヘッダ+UDPペイロード)」に

    QUICをゆっくり解説(3):QUICパケットの構造 | IIJ Engineers Blog
  • TLS 1.3の標準化と実装 | IIJ Engineers Blog

    IIJ-II 技術研究所 技術開発室の山です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも

    TLS 1.3の標準化と実装 | IIJ Engineers Blog
  • ドキュメントの継続的な開発方法 | IIJ Engineers Blog

    私はソフトウェア開発を主体とするエンジニアで、 クラウドサービスの開発・運用 分散処理技術の検証とサービス利用の検討 社内の開発支援環境の開発・運用 などの業務に従事していますが、今回の記事は業務とは直接的な関係は無く、私が会社で勝手自発的に行っている取り組みについて書きたいと思います。 昨今、インターネットは生活に深く浸透し、クラウドサービスを利用することで安く簡単にWebサービスを開発、公開できるようになりました。Web技術の進化や流行の移り変りも非常に激しく、既存サービスの機能追加や新規サービスの開発は頻繁に行われています。それは弊社も例外ではありません。 このような開発の現場では、リーンソフトウェア開発への取り組みなど開発手法の最適化が積極的に行われ、様々なベストプラクティスが生みだされています。それらのベストプラクティスには、 継続的インテグレーション や 継続的デプロイメント

    ドキュメントの継続的な開発方法 | IIJ Engineers Blog
  • 1