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:
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.
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:
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 :-)
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
On 2010/07/27 10:56, Janko Mivšek wrote:
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?
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
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 frank.shearar@angband.za.org wrote:
On 2010/07/27 10:56, Janko Mivšek wrote:
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?
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
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:
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 Sheararfrank.shearar@angband.za.org wrote:
On 2010/07/27 10:56, Janko Mivšek wrote:
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?
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 28 July 2010 10:49, Frank Shearar frank.shearar@angband.za.org 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.
frank
On 2010/07/28 08:40, Igor Stasenko wrote:
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 Sheararfrank.shearar@angband.za.org wrote:
On 2010/07/27 10:56, Janko Mivšek wrote:
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?
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 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
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 2010/07/28 10:10, Janko Mivšek 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.
I know, and agree wholeheartedly!
CTI as a part of the convergence toolbox is essentially used for two simple but very powerful things:
- notifying your application that someone is calling,
- 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.
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
Janko
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
On 2010/07/28 05:56, Andreas Raab wrote:
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.
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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Frank Shearar -
Igor Stasenko -
Janko Mivšek