Re: CoAP Methods implementation

On 29/03/2012 7:23 p.m., parashuram lamani wrote:
> On Wed, Mar 28, 2012 at 6:36 PM, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
>> On 29/03/2012 12:29 a.m., parashuram lamani wrote:
>>
>>> On Wed, Mar 28, 2012 at 3:45 PM, Amos Jeffries wrote:
>>>> Hi again Parashuram,
>>>>
>>>>
>>>> On 28/03/2012 10:35 p.m., parashuram lamani wrote:
>>>>> Dear all,
>>>>> squid-3.2.0.16 has support for coap protocol but when i make any coap
>>>>> request it returns unsupported method error so i think coap methods
>>>>> have not been implemented, so i have decided implement some basic
>>>>> methods such as put, get,post and delete. can anyone guide me how to
>>>>> start about it.
>>>>
>>>> method errors? I only added the CoAP-over-HTTP support for relay of
>>>> coap:://
>>>> URLs to another HTTP proxy for gateway operations to be handled by that
>>>> peer. Following from our last discussion about this.
>>>>
>>>> In teh current support is only HTTP over TCP operation where methods get
>>>> written through alongside the URL so there should not be errors involved
>>>> in
>>>> any of that. Which makes me wonder what exactly is your attempted setup
>>>> so
>>>> far?
>>> Let me explain you my setup
>>>
>>> <coap-client><----------><squid web
>>> proxy><---------><coap-server>
>>> <http-client>
>>> <http-coap-mapping>
>>>
>>> http to coap and coap to http is implemented on server side.
>>> all http request for coap resources are successfull. i.e if it is
>>> http:// request for CoAP packets (resourses) server side will first
>>> map it to coap request then converts entire coap response to http
>>> response and delivers to http client
>>
>> So you have written this proxy<->server maping already? could we get a patch
>> audit submission for that please? this is a good stage to settle that half
>> the work into mainstream and check that its right with regards to how things
>> operate.
> Amos, I would be very happy to submitt patch for proxy<->server
> mapping but I think you got me wrong here, I've not implemented
> proxy<->server in squid. my setup and scenario is as follows.
>
> 1st scenario
>
> <coap-client>------<coap-server and http-coap mapping module>
> <http-client>
>
> 2nd scenario
> <coap-client>--<squid>--<coap-server and http-coap mapping module>
> <http-client>
>
> here mapping is taking place at coap-server side which has separate
> mapping module.
>
> Amos if you people guide me I can write proxy<->server mapping.
>>
>>>> Are you attempting to receive CoAP packets and convert to an HTTP request
>>>> or
>>>> to receive HTTP coap:// request and convert to CoAP packets?
>>>>
>>> What I am trying is just CoAP request which should return CoAP
>>> packets, nothing is needed to be mapped when it is coap:// request
>>> Amos I hope you understood my test scenario, if anything else needed let
>>> me know
>>
>> You mean the client<->squid CoAP connection is what you are trying to get
>> going?
> Exactly,
>> Relaying packets from client to server without mapping is trivial. Just call
>> your server component start function directly with the received client
>> packet and/or data. This may involve changing it a little or adding an
>> alternative version of it.
>>
>> If you want to get adaptation, filtering, or caching you have to map to and
>> from Squids internal HttpRe* structures which those features make use of.
>>
> Caching is the main purpose why I am inserting squid in between,

Okay lets build the process pathway from the top then...

* update src/cf.data.pre creating an entry for coap_port.
   - you can model this on htcp_port entry in the same file.

* update src/structs.h to create Config.Sockaddr.coap port config variable.

Did you look at the HTCP systems as I suggested a while back?

* add src/coap.h and src/coap.cc for the port open/close/recv management
functions. Copy the code from htcp.h and htcp.cc as needed, changing the
"htcp" prefix of things to "coap".

* update src/main.cc to call the CoAP open/close functions in same
places the HTCP and ICP open/close functions are called.

If it builds at this point you should be able to configure and open
listening ports (but not do anything with the packets arriving there).

Amos
Received on Tue Apr 03 2012 - 07:11:35 MDT