<?xml version='1.0' encoding='UTF-8'?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2026-04-15T04:28:58Z</responseDate>
  <request identifier="oai:ipsj.ixsq.nii.ac.jp:00200852" metadataPrefix="oai_dc" verb="GetRecord">https://ipsj.ixsq.nii.ac.jp/oai</request>
  <GetRecord>
    <record>
      <header>
        <identifier>oai:ipsj.ixsq.nii.ac.jp:00200852</identifier>
        <datestamp>2025-01-19T21:13:37Z</datestamp>
        <setSpec>6164:6165:6244:9989</setSpec>
      </header>
      <metadata>
        <oai_dc:dc xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns="http://www.w3.org/2001/XMLSchema" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
          <dc:title>分散型MQTT Brokerを活用したコンポーネント選択手法の比較評価</dc:title>
          <dc:title>A Comparative Evaluation of a Component Selection Method using Distributed MQTT Broker</dc:title>
          <dc:creator>安田, 和磨</dc:creator>
          <dc:creator>石原, 真太郎</dc:creator>
          <dc:creator>秋山, 豊和</dc:creator>
          <dc:subject>ネットワーク設計</dc:subject>
          <dc:description>近年，Internet of Things (IoT) デバイスの普及に伴い，多種多様になる IoT アプリケーションの要求に応えるために，エッジコンピューティングが注目されている．一方で，センサから得られるデータストリームをマイクロサービスを組み合わせて処理する Dataflow platform の開発も進められている．エッジコンピューティング環境での Dataflow platform にはネットワーク間の地理的距離とコンポーネント配備先のリソース状況を考慮した通信が求められる．これまで，P2P 構造化オーバレイを活用し，コンポーネントに地理的な情報と値を付与し，送信元で明示的に配送先を指定による通信及び負荷分散をする手法が提案されているが，配送先の決定にリソース状況は考えられていない．配送先を適切に決定するには一度各配備先のリソース状況を収集する必要がある．本研究では，地理的距離を考慮した配送が可能な分散型の MQTT Broker PIQT において，収集した値をオーバレイ上で集約値として扱い，それを用いた条件付き Multicast を拡張することで，リソース状況を考慮し適切なコンポーネント選択を可能とする Anycast 機構を導入する．集約値はオーバレイを維持するためのメッセージと一緒にリソース状況を収集するため，必要なメッセージ数を削減できるが，情報の鮮度は更新頻度に依存する．リソースの状態が更新されない最悪のケースの Anycast 機構と一度問い合わせる配送方法で要したメッセージの総ホップ数を比較調査した．また，集約値の有無により増加すると考えられる維持メッセージのペイロードサイズも同様に調査した．それらの結果を用いて，集約値を用いた Anycast により総ホップ数が抑えられることと，維持メッセージのサイズにより負荷が少なくなったことを明らかにした．</dc:description>
          <dc:description>conference paper</dc:description>
          <dc:publisher>情報処理学会</dc:publisher>
          <dc:date>2019-11-28</dc:date>
          <dc:format>application/pdf</dc:format>
          <dc:identifier>インターネットと運用技術シンポジウム論文集</dc:identifier>
          <dc:identifier>2019</dc:identifier>
          <dc:identifier>25</dc:identifier>
          <dc:identifier>32</dc:identifier>
          <dc:identifier>https://ipsj.ixsq.nii.ac.jp/record/200852/files/IPSJ-IOTS2019004.pdf</dc:identifier>
          <dc:language>jpn</dc:language>
        </oai_dc:dc>
      </metadata>
    </record>
  </GetRecord>
</OAI-PMH>
