Neil Hunter <neil.hunter@xxxxxxxxxxxxxxxxxxx>
said:
> On Thu, 6 Jul 2000, Ben Fowler wrote:
>
> > WAP is a stack rather than a protocol, thus WSP is carried in WTP
> > a bit like TCP is carried in IP. Indeed, I refer to port 9201 data
> > as WSP/WTP.
>
> Hehe - don't you just love definitions ;)
> I'd agree that WAP is a protocol stack, but I have to disagree with your
> analogy to TCP/IP. In fact WSP is only carried in WTP *if* the session is
> connection-oriented. For connection-less mode, WSP is carried raw.
Sure - I am concentrating on networking via port 9201 at present
> I think we are saying the same thing, but perhaps the place to do it is in
> the packet-udp section. I.e. packet-udp hands off connection-mode data to
> WTP and connection-less to WSP. WTP processes its data and then passes
> the remainder off to WSP. I'm not sure if this level of "chaining" (for
> want of a better term) is supported.
You have raised two points there, in the first place I am working on the
basis that (to take an example) packet-udp will send packets on port 9201
one way and those on 9200 another. I have not worked out the details,
and I have not taken it any further.
> > I also think that the dissectors should be kept separate, so although
> > I consider this a WAP project and there is a single wap.h header file,
> > I have put the code into separate files wsp.c and wtp.c.
>
> Totally agree. This is all related to the WAP Protocol stack - so we'll
> keep it together, but modular.
If you want you can take my file labelled wsp.c and see whether it can
be edited to fulfill simultaneously the two things that you suggest
i) called by wtp.c to continue the dissection of wsp/wtp traffic
ii) called by packet-udp.c under circumstances determined by you
Obviously I feel that (i) is the priority here, but if you can achieve (ii)
we are ahead of the game because two protocols will be working for the
price of one. I think that it is important to ascertain when packet-udp.c
called wsp.c and how this is done; but I leave that up to you.
[...]
> ---------------------------------------
> This email is confidential ...
It is not going to stay confidential posted to a mailing list and
archived at < URL:http://ethereal.zing.org/lists/ethereal-dev/200007/ >
Ben.
