[ANN] DnsClient: More protocol fun

Folks -

I just finished another fun little protocol implementation. DnsClient is
a client for DNS lookups of all sorts. Why implement the DNS protocol
you ask? Well, because 1) it's fun, 2) it's educational, and 3) it's
non-blocking. The latter is actually interesting, we've found that
occasionally we get very long VM blocking due to synchronous name lookup
performed in the Unix socket code.

You can install DnsClient from Squeaksource:

        (Installer ss project: 'ar')
                install: 'DnsClient-Core';  "all the code"
                install: 'DnsClient-Tests'; "the tests"
                install: 'DnsClient-Hacks'. "use DnsClient when present"

DnsClient should work well but beware that on Windows it will currently
use the deefault fallback name servers (Google DNS and OpenDNS) since I
still need to implement the primitive to return the proper resolv.conf
content (which is spread out in the Windows registry). Consequently, if
you're trying look up local names or if you are behind a firewall, these
addresses will fail until I've implemented the primitive proper.

Cheers,
   - Andreas

On 2010/07/27 09:24, Andreas Raab wrote: Nice!

So if one wanted to implement some of the stranger records - NAPTR
springs to mind - one would just hack DnsRecord>>readFrom: and add an
appropriate case, yes? (For NAPTR (RFC 2915) that's 35).

(SIP uses NAPTR records as part of its lookup mechanism, defined in RFC
3263 SIP: Locating SIP Servers.)

The attached OUGHT to do it. I don't know of any public servers that
user NAPTR *cough* and I'd need to look up local names to properly test
against my local test setup.

frank

On 7/27/2010 1:33 AM, Frank Shearar wrote:
> So if one wanted to implement some of the stranger records - NAPTR
> springs to mind - one would just hack DnsRecord>>readFrom: and add an
> appropriate case, yes? (For NAPTR (RFC 2915) that's 35).

Yes, exactly.

> (SIP uses NAPTR records as part of its lookup mechanism, defined in RFC
> 3263 SIP: Locating SIP Servers.)

Sweet! I had no idea. Josh will be glad to hear that I think :-)

> The attached OUGHT to do it. I don't know of any public servers that
> user NAPTR *cough* and I'd need to look up local names to properly test
> against my local test setup.

Yes, I'll try to implement the primitive on Windows sometime soon.

Cheers,
   - Andreas

On 2010/07/27 10:38, Andreas Raab wrote:
I really ought to revive my sadly-dormant SIP stack on SS.

>> The attached OUGHT to do it. I don't know of any public servers that
>> user NAPTR *cough* and I'd need to look up local names to properly test
>> against my local test setup.
>
> Yes, I'll try to implement the primitive on Windows sometime soon.

I'll definitely try it out when you've had a go.

frank

Hi Frank,

On 27. 07. 2010 10:48, Frank Shearar wrote:

>>> (SIP uses NAPTR records as part of its lookup mechanism, defined in RFC
>>> 3263 SIP: Locating SIP Servers.)
>>
>> Sweet! I had no idea. Josh will be glad to hear that I think :-)
>
> I really ought to revive my sadly-dormant SIP stack on SS.

This sounds very interesting! Have you some further projects in mind
with this SIP stack? Somewhere in a CTI (Computer Telephony Integration)
direction?

Best regards
Janko

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On 2010/07/27 10:56, Janko Mivšek wrote:
It's really just a stub - I started parsing the SIP messages, and then
Real Life soaked up all my time. (I've implemented a complete stack in
Delphi, so at least I know the protocol reasonably well. That's half the
battle.)

I'm not familiar with the term Computer Telephony Integration.

With a completed SIP stack, what I'd really like to do is make it good
enough for Josh to use :). There are all sorts of interesting things one
can do with a SIP stack. My _personal_ goal would be to get a proper
text-using client up and running, and then extend it to a Total
Conversation client (voice/video/text).


frank

On 7/27/2010 1:48 AM, Frank Shearar wrote:
>>> The attached OUGHT to do it. I don't know of any public servers that
>>> user NAPTR *cough* and I'd need to look up local names to properly test
>>> against my local test setup.
>>
>> Yes, I'll try to implement the primitive on Windows sometime soon.
>
> I'll definitely try it out when you've had a go.

Give it a shot. I made a quick respin of the VM available as 4.1.1 which
includes a (rather cheap) version of the dns info primitive so if you
download the VM from:

http://squeakvm.org/win32/release/SqueakVM-Win32-4.1.1-bin.zip

and then fetch the latest version of DnsClient:

(Installer ss project: 'ar')
        install: 'DnsClient-Core';
        install: 'DnsClient-Tests';
        install: 'DnsClient-Hacks'.

You should be good to go. Anyone else who has got some time to spare I'd
be interesting to find out if the data returned by "DnsClient default
dnsInfo" is correct when compared with, e.g., ipconfig /all.

Cheers,
   - Andreas

Yay. Been there did that :)
Unfortunately , it was done in C++ and was pain to test and debug.

On 27 July 2010 12:34, Frank Shearar <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

On 2010/07/28 05:56, Andreas Raab wrote: Good news: your primitive works just fine. I can resolve NAPTR records
defined in my local environment.

Bad news: my NAPTR parsing's completely wrong, because I (incorrectly)
read a diagram and not the normative text around the diagram.

Good news: the attached correctly parses NAPTR records.

DnsClient default lookupRecordsFor: 'leo-ix.net' deadline: 15 type: 35

gives:

  {DnsRecord(leo-ix.net, type: 35, flags: 's', replacement:
'_sips._tcp.leo-ix.net', preference: 50, order: 50, services:
'SIPS+D2T', regexp: '') . DnsRecord(leo-ix.net, type: 35, flags: 's',
replacement: '_sip._tcp.leo-ix.net', preference: 60, order: 90,
services: 'SIP+D2T', regexp: '') . DnsRecord(leo-ix.net, type: 35,
flags: 's', replacement: '_sip._udp.leo-ix.net', preference: 70, order:
100, services: 'SIP+D2U', regexp: '')}

corresponding to what appears in the zonefile as:
;;                   order pref flags service      regexp  replacement
leo-ix.net. IN NAPTR 50    50   "s"   "SIPS+D2T"   ""      _sips._tcp
leo-ix.net. IN NAPTR 90    60   "s"   "SIP+D2T"    ""      _sip._tcp
leo-ix.net. IN NAPTR 100   70   "s"   "SIP+D2U"    ""      _sip._udp

frank

A SIP stack is a non-trivial amount of work to implement. Several
man-years to get a basic stack working (at least, when you're me). (I
wrote mine in Delphi.)

It's an intricate protocol. I think it's a very _abstract_ protocol,
designed to be as open-ended as possible, which is why, IMO at least,
it's such a beast. But then, when it's implemented and rolled out to
devices with nothing but firmware, it's hard to change your mind.

I think the only thing that seriously makes me froth at the gills is
that both RFC 2543 (the old SIP) and RFC 3261 (the new SIP) BOTH use
"SIP/2.0" as protocol identifiers.

frank

On 2010/07/28 08:40, Igor Stasenko wrote:

On 27. 07. 2010 11:34, Frank Shearar wrote:

> I'm not familiar with the term Computer Telephony Integration (CTI).

Main usage of a SIP (Session Initialization Protocol) nowadays is in IP
phones and one of the main selling points of the IP over classical
telephony is so called "convergence" between different means of
communication, and specially between telephony and computers.

Well, in reality so far it is more a selling point than much meat, but
there is a potential and the SIP protocol is essential part of the
convergence toolboox, that's why it is good to have a SIP protocol
implemented in Smalltalk.

CTI as a part of the convergence toolbox is essentially used for two
simple but very powerful things:

        1. notifying your application that someone is calling,
        2. calling by "one-click" from your application

Specially the first one is very important for systems like CRM (Customer
Relation Management). And because a big percentage of applications are
dealing directly or indirectly with customers, they have a need for a
CRM and therefore also for a CTI.

Most basic example: a customer calls you and his webpage is poped-up in
front of you to read past conversations with him in few seconds before
you pick-up the phone and start prepared the conversation with him.

The whole trick is in those few seconds and those seconds are essential
for a much much better income of such customer call. That's why the CTI
is so important and that's why it is important to be supported from our
Smalltalk apps too!

Janko

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On 2010/07/28 10:10, Janko Mivšek wrote:
I know, and agree wholeheartedly!

Right, OK. The Wikipedia made it sound like CTI was making your computer
aware that a _device_ had received a call.

CTI still sounds like something that uses a SIP client of some kind,
rather than something that SIP itself does, right?

> The whole trick is in those few seconds and those seconds are essential
> for a much much better income of such customer call. That's why the CTI
> is so important and that's why it is important to be supported from our
> Smalltalk apps too!

We can still do this by wrapping around an existing library.

I started my SIP stack just to use Smalltalk in anger, on a complicated
network protocol. If others pitch in and we make something usable,
great! (And of course I'd love to have my SIP stack getting used all
over the place.)

But if people just want to be able to use SIP from within Squeak, it's
possible that the faster route is to write a plugin that talks to
something like reSIProcate (C++), or a suitable wrapper around my Delphi
stack, or similar.

frank

On 28 July 2010 10:49, Frank Shearar <[hidden email]> wrote:
> A SIP stack is a non-trivial amount of work to implement. Several man-years
> to get a basic stack working (at least, when you're me). (I wrote mine in
> Delphi.)
>
well, it was paid job and i woked in a team on that.

> It's an intricate protocol. I think it's a very _abstract_ protocol,
> designed to be as open-ended as possible, which is why, IMO at least, it's
> such a beast. But then, when it's implemented and rolled out to devices with
> nothing but firmware, it's hard to change your mind.
>
> I think the only thing that seriously makes me froth at the gills is that
> both RFC 2543 (the old SIP) and RFC 3261 (the new SIP) BOTH use "SIP/2.0" as
> protocol identifiers.
>

One of things, which i found bad is lack of conferecing support in
earlier SIP specs.
Nevertheless, our software were able to communicate PC-to-PC and
PC-to-IP phone (hardware)
through IP telephony service.



--
Best regards,
Igor Stasenko AKA sig.