IETF Logo Mail Archive

Re: [core] Using CoAP for P2P

Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com> Thu, 02 April 2020 08:04 UTC

Return-Path: <abhijan.bhattacharyya@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9A3A0D17 for <core@ietfa.amsl.com>; Thu, 2 Apr 2020 01:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXj5OjLqP8D1 for <core@ietfa.amsl.com>; Thu, 2 Apr 2020 01:04:00 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4944D3A0D16 for <core@ietf.org>; Thu, 2 Apr 2020 01:04:00 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id a43so3019740edf.6 for <core@ietf.org>; Thu, 02 Apr 2020 01:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ri6ei4cgDguqv469TVwbh91Tii7GFlRcq4f6G7QLlA8=; b=UmuzyEJkFPSpjKNGiXisKx8ZOTQeg82YBvCUou9lIq/0g3Tpp8WFcxdmMN/0fapF42 IG9isk8c56FChas9XPhNqypwOVARj/qtT8FGiIWtXApNvwcUp6sdVIOOqaW2iWAHvW/5 McNWyJGTyYXCzDAzksu69VdHzwJjmFT+fGbkOWHxNz9qgNkOc+sh02SRAZPTszv6oE+A 4MSIgw27kpZkTy+yhqXKaWTeY9gE8CMz0JZDfAgta/KuXR99VOXWtSIieyvJx5KVglFU hTHi4QjiDxyw0CBJmK6BinuF9EgDORrN0VuFT895rlRt87TGiKpveLOSAcgm9Lh/a+wq L2aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ri6ei4cgDguqv469TVwbh91Tii7GFlRcq4f6G7QLlA8=; b=MOK2EdqAldrzLFL3eYEsIRsK2qpLa8wc8tQsS7kQj54j/ZGIR0oEpivHpRBV2coqih 91MWmeRCwna1vodb1rl25vFvisMyvxXDI8i+c274bb9vC7ACogJgKUTShlz62K7lkBtI Am2rhQKlgifdeVHPaLSWHgzb63FcnBSib09tHlw7w8dLccDnHvt5bGDfYDZ0A4H+BPcu hDC2VI8JpYMyy8JxAxfAP8GjYaZo9wGuhe9mcKn2lu0bk0iaOcpBp/IIA8EfBj3gnyBh /CYsZ93qAfEXu3npEA8sThUhxwok87Mw4FuE8D3QHP+gfzR2i7RIHf5J+88Mwe3TQs5Q 2DKw==
X-Gm-Message-State: AGi0PuZ40MJTu73xanF8hv9q++nL6KW/sWlQp0BktChAiD5JY73LyT1n kx0jBZBJyb4Dz2TZObV+QRixb0VoeXayxQIj+Tw=
X-Google-Smtp-Source: APiQypLWupfIUo8BCSamTh4lfS5DOTe9mvlhZDwj4hwoMQ0/O7F1l2H6LRzPN3EOVptREieRwIUUZE1XvNEUWU1vXSs=
X-Received: by 2002:a50:9e45:: with SMTP id z63mr1607718ede.338.1585814638637; Thu, 02 Apr 2020 01:03:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAEW_hyzh3FAvHi1eTkbyGn99o4nFgcH1xP90FdQ6N9sHsAJVYQ@mail.gmail.com> <A8E6E9AA-2E34-439E-8761-53385086CDB9@arm.com>
In-Reply-To: <A8E6E9AA-2E34-439E-8761-53385086CDB9@arm.com>
From: Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com>
Date: Thu, 02 Apr 2020 13:33:47 +0530
Message-ID: <CAEW_hyy+0fViN8dMWiCi_QHjeD5J4DUAnoRUg5MAKS6fQ3DzcQ@mail.gmail.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>
Cc: core <core@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003734d005a24a3eae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/IIwJXP6a825-bPyflpHrm_3kDiM>
Subject: Re: [core] Using CoAP for P2P
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 08:04:02 -0000

Hi Thomas,
What I am looking at is a situation where I have two nodes each having a
time-varying resource. Both want to push the states of the respective
resource to the other node within a common application context. However,
these exchanges are naturally asynchronous. May be I can think of it more
like a chat. A typical client-server or observe relationship will not serve
the purpose. Actually both should have a client and server instance running
under a common application. Then either each can *observe* the other, or
can *post* the other. That is how we can do that without a central server.

If my understanding is right, according to CoAP specification, the nodes
which can have both server and client (to the origin server) are
"intermediary" nodes. The only example of "intermediary" considered in the
spec is the proxy node. But, anyway the situation in this case does not
concern with intermediary. Both are origin server and end-client together.

Is there any standardized mechanism to handle this situation?

Thanks.

On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <Thomas.Fossati@arm.com>
wrote:

> Hi Abhijan,
>
> On 01/04/2020, 12:31, Abhijan Bhattacharyya <
> abhijan.bhattacharyya@gmail.com> wrote:
> > Is there any standardized mechanism to use CoAP for a P2P connection?
>
> Not sure whether RFC 7650 would fit your needs but worth having a
> look -- if you haven't already.
>
> cheers
> --
>
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>


-- 
Regards,
Abhijan Bhattacharyya,
*Technologist by profession [IoT| Internet Protocols| 5G]*

v2.23.0 | Report a Bug | By Email