ICS Wish List

[Angus Robertson 574]

This list is possible additions to ICS, new protocols and functionality, none of which is guaranteed...  Open to suggestions for other possible protocol additions or improvements.  Personally, I'm unlikely to look at any of this stuff for several months, unless my company has an urgent need for something new.  But if several other users are all looking for the same thing, I can help co-ordinating improvements.

Protocol: STUN client and server
Why: Session Traversal Utilities for NAT allows finding a public IP address while behind a NAT router, by contacting a STUN server.  Used by public servers and clients that need to tell other applications how to contact them.  Also some client protocols like a host name, like SMTP.
Difficulty: low, simple protocol, easy to implement.
Benefits: medium, saves configuring the IP manually.

Protocol: RDAP Client
Why: Registration Data Access Protocol is the replacement for the Whois protocol, using HTTPS REST and Json protocols. Both domains and IP addresses.
Difficulty: low, simple protocol, easy to implement.
Benefits: low, Whois is heavily censored now.

Protocol: Roughtime client and server
Why: replacement for NTP and SNTP network time protocols (from Google), with security.
Difficulty: low, simple protocol.
Benefits: low, usually get time from Windows.

Protocol: HTTP/2 for HTTP client and server
Why: More efficient version of HTTP/1.1, particularly for web pages with dozens of elements, compresses headers.
Difficult: moderate, extra DLL, messy, lots to change.
Benefits: low, ICS is rarely used to download complex web pages, perhaps
more important for the HTTP server.

Protocol: SASL for SMPT and POP3 clients
Why: Simple Authorisation and Security Layer adds OAuth2 for SMTP and POP3, safer than clear authentication.
Difficulty: low, OAuth2 already done.
Benefits: high, where the email provider requires it.

Protocol: OAuth1 for Twitter
Why: Twitter uses OAuth1 rather than the easier and more recent OAuth2 almost everyone else uses.
Difficulty: low, uses HMAC which is done already.
Benefits: high, if you want to send tweets.

Protocol: DNS over HTTPS (DOH)
Why: secure DNS can not be intercepted and modified.
Difficulty: ICS already has a TDnsQueryHttps component and sample, but causing it to be used by TWSocket and other components at low level could get messy and link in all the REST and Json units.
Benefits: low, Microsoft is threatening to support DOH, probably only
Windows 10/2019.

Protocol: MQTT
Why: MQ Telemetry Transport is used to send messages between devices, including IoT.
Difficulty: ICS MQTT project n GutHub, needs integration.
Benefits: high, if you need the protocol.

Protocol: Websockets server
Why: A full duplex version of HTTP often used for server push to dynamically update web pages.
Difficulty: ICS websockets project in GutHub, needs update and integration.
Benefits: high, if you need the protocol.

Protocol: SChannel SSL/TLS Support
Why: avoid distributing OpenSSL DLLs by using SSL/TLS protocol APIs built into Windows. Downside is Microsoft often takes years to support new protocols and often only in the latest operating systems

Difficulty: high, needs to be done at the lowest levels, risks adding bugs for OpenSSL if both supported, need to replace a lot of OpenSSL encryption APIs with Windows APIs, and certificate APIs.
Benefits: low, unless you really hate DLLs.

Protocol: POP3 Server, IMAP Client and Server
Why: because these are missing and we all use email.
Difficulty: moderate, lot of new new code.
Benefits: high, if you need them.

Platform: Better C++ and MacOS Support
Why: we don't do much testing on C++ and MacOS due to lack of volunteers to do this regularly.  We lack samples for C++ and MacOS.
Difficulty: high, users want someone else to do the work.
Benefits: high, for C++ and MacOS users.

Platform: Support for mobile apps and Linux
Why: more platforms.
Difficulty: very high, probably at least one man year effort, maybe more.
Benefits: high, for mobile apps and Linux.
 

Angus

 

[Fr0sT.Brutal 900]

1 hour ago, Angus Robertson said:

Difficulty: high, needs to be done at the lowest levels, risks adding bugs for OpenSSL if both supported, need to replace a lot of OpenSSL encryption

Not so high actually at least to have it working at a simplest level.

[FPiette 383]

In my opinion, OAuth1 (Twitter), IMAP (mail client and server) and Linux (Including Android) are the most demanded.

 

For Linux/Android, I have already been asked a lot of time. I always answered: when I need it for my own business or if someone want to fund the project. Remember ICS-SSL was born because I wrote it when a group of supporters agreed to pay a little fee to fund the development. That was a success as you know. After the initial period of exclusivity for those having paid, ICS-SSL is now merged with ICS.

[Angus Robertson 574]

I did finally get a Twitter developer account a while back, but always seem to be fire fighting something else when I try to get back to OAUth1.

 

Angus

[Guest]

Hello,

  

   

 I am new to ICS Internet components but as little as I could see, I am aware of how powerful they are.

 

 I am not sure if there is an ICS HTTP server component that wrappers 'http.sys' and provides HTTP services at the kernel level, that not by chance is used by IIS. If not, I think that such a component would be a GREAT contribution to the creation of REST web services, for instance. What do you think?

 

    

[Angus Robertson 574]

No, the ICS HTTP server is independent of the Windows http.sys API, While a server running at kernel level is potentially more efficient than one at application level, all the REST and authentication stuff would still be at application level.  You are also restricted to server facilities Microsoft chooses to offer, which are present means no TLS/1,3 or modern ciphers, for instance.  So really only an advantage for very heavy load servers.

 

Angus

 

[Guest]

20 minutes ago, Angus Robertson said:

No, the ICS HTTP server is independent of the Windows http.sys API, While a server running at kernel level is potentially more efficient than one at application level, all the REST and authentication stuff would still be at application level.  You are also restricted to server facilities Microsoft chooses to offer, which are present means no TLS/1,3 or modern ciphers, for instance.  So really only an advantage for very heavy load servers.

 

Angus

 

Ok, thank you for your response!

[Max Terentiev 0]

What about IOCP sockets (on windows) and EPOLL (on linux) for better performance and scale on multi-core CPU ?

[Angus Robertson 574]

Better use of multiple CPUs needs threads, which we generally try to avoid in ICS, but bring the ICS threaded socket server up to date is on my list, and perhaps allowing the web server to use it.

 

I'm aware there are Windows APIs that offer performance improvements over our existing use of sockets, by sending and receiving entire files, but you then lose control over what is happening and SSL becomes problematic.  But it's something we can look at.

 

Angus