Commit Graph

487 Commits

Author SHA1 Message Date
Norman Maurer
6600ea3fac Add OpenSslClientContext to allow creating SslEngine for client side
Motivation:

We only support openssl for server side at the moment but it would be also useful for client side.

Modification:

* Upgrade to new netty-tcnative snapshot to support client side openssl support
* Add OpenSslClientContext which can be used to create SslEngine for client side usage
* Factor out common logic between OpenSslClientContext and OpenSslServerContent into new abstract base class called OpenSslContext
* Correctly detect handshake failures as soon as possible
* Guard against segfault caused by multiple calls to destroyPools(). This can happen if OpenSslContext throws an exception in the constructor and the finalize() method is called later during GC

Result:

openssl can be used for client and servers now.
2014-12-22 20:10:24 +01:00
Scott Mitchell
f879614c61 Java ALPN provider version update
Motivation:

There was a bug in the Java ALPN library we are using.  A new version was released to fix this bug and we should update our pom.xml to use the new version.

Modifications:

Update pom.xml to use new ALPN library.

Result:

Newer versions of JDK (1.7_u71, 1.7_u72, 1.8_u25) have the bug fixed.
2014-12-16 16:25:01 -05:00
Trustin Lee
bf77bb4c3a Fix build errors due to missing dependency 2014-12-14 21:29:26 +09:00
Trustin Lee
d6160208c3 Compress the heap dump generated by TestUtils.dump()
Motivation:

It takes too long to download the heap dump from the CI server.

Modifications:

Compress the heap dump as much as possible.

Result:

When heap dump is generated by certain test failure, the generated heap
dump file is about 3 times smaller than before, although the compression
time will increase the build time when the test fails.
2014-12-14 12:01:17 +09:00
Scott Mitchell
1293aba28e HTTP/2 Draft 16
Motivation:
HTTP/2 draft 16 has been released https://tools.ietf.org/html/draft-ietf-httpbis-http2-16.

Modifications:
The HTTP/2 codec should be updated to support draft 16.

Result:
HTTP/2 codec is draft 16 compliant.
2014-12-11 18:58:59 -05:00
Trustin Lee
078072632a Fix dependency issues with hamcrest
Motivation:

We use 3 (!) libraries to build mock objects - easymock, mockito, jmock.
Mockito and jMock pulls in the different versions of Hamcrest, and it
conflicts with the version pulled by jUnit.

Modifications:

- Replace mockito-all with mockito-core to avoid pulling in outdated
  jUnit and Hamcrest
- Exclude junit-dep when pulling in jmock-junit4, because it pulls an
  outdated Hamcrest version
- Pull in the hamcrest-library version used by jUnit explicitly

Result:

No more dependency hell that results in NoSuchMethodError during the
tests
2014-12-04 17:53:35 +09:00
Scott Mitchell
f8af84d599 ALPN should allow handshake failure if no compatible protocols found
Motivation:
If there are no common protocols in the ALPN protocol exchange we still compete the handshake successfully.  This handshake should fail according to http://tools.ietf.org/html/rfc7301#section-3.2 with a status of no_application_protocol.  The specification also allows for the server to "play dumb" and not advertise that it supports ALPN in this case (see MAY clauses in http://tools.ietf.org/html/rfc7301#section-3.1)

Modifications:
-Upstream project used for ALPN (alpn-boot) does not support this.  So a PR https://github.com/jetty-project/jetty-alpn/pull/3 was submitted.
-The netty code using alpn-boot should support the new interface (return null on existing method).
-Version number of alpn-boot must be updated in pom.xml files

Result:
-Netty fails the SSL handshake if ALPN is used and there are no common protocols.
2014-10-30 19:39:31 -04:00
nmittler
e809f97136 Upgrading HTTP/2 hpack to latest version
Motivation:

Twitter hpack has upgraded to 0.9.1, we should upgrade to the latest.

Modifications:

Updated the parent pom to specify the dependency version. Updated the
http2 pom to use the version specified by the parent.

Result:

HTTP/2 updated to the latest hpack release.
2014-10-16 08:59:08 -07:00
Trustin Lee
fa248cecb5 Name resolver API and DNS-based name resolver
Motivation:

So far, we relied on the domain name resolution mechanism provided by
JDK.  It served its purpose very well, but had the following
shortcomings:

- Domain name resolution is performed in a blocking manner.
  This becomes a problem when a user has to connect to thousands of
  different hosts. e.g. web crawlers
- It is impossible to employ an alternative cache/retry policy.
  e.g. lower/upper bound in TTL, round-robin
- It is impossible to employ an alternative name resolution mechanism.
  e.g. Zookeeper-based name resolver

Modification:

- Add the resolver API in the new module: netty-resolver
- Implement the DNS-based resolver: netty-resolver-dns
  .. which uses netty-codec-dns
- Make ChannelFactory reusable because it's now used by
  io.netty.bootstrap, io.netty.resolver.dns, and potentially by other
  modules in the future
  - Move ChannelFactory from io.netty.bootstrap to io.netty.channel
  - Deprecate the old ChannelFactory
  - Add ReflectiveChannelFactory

Result:

It is trivial to resolve a large number of domain names asynchronously.
2014-10-16 17:10:36 +09:00
Trustin Lee
de9c81bf6e Add proxy support for client socket connections
Related issue: #1133

Motivation:

There is no support for client socket connections via a proxy server in
Netty.

Modifications:

- Add a new module 'handler-proxy'
- Add ProxyHandler and its subclasses to support SOCKS 4a/5 and HTTP(S)
  proxy connections
- Add a full parameterized test for most scenarios
- Clean up pom.xml

Result:

A user can make an outgoing connection via proxy servers with only
trivial effort.
2014-10-14 12:40:33 +09:00
Idel Pivnitskiy
c6b2c5a320 Implemented LZMA frame encoder
Motivation:

LZMA compression algorithm has a very good compression ratio.

Modifications:

- Added `lzma-java` library which implements LZMA algorithm.
- Implemented LzmaFrameEncoder which extends MessageToByteEncoder and provides compression of outgoing messages.
- Added tests to verify the LzmaFrameEncoder and how it can compress data for the next uncompression using the original library.

Result:

LZMA encoder which can compress data using LZMA algorithm.
2014-09-15 15:14:15 +02:00
Scott Mitchell
5f232b2220 ALPN java implementation
Motivation:

Netty only supports a java NPN implementation provided by npn-api and npn-boot.
There is no java implementation for ALPN.
ALPN is needed to be compliant with the HTTP/2 spec.

Modifications:
-SslContext and JdkSslContext to support ALPN
-JettyNpn* class restructure for NPN and ALPN common aspects
-Pull in alpn-api and alpn-boot optional dependencies for ALPN java implementation

Result:

-Netty provides access to a java implementation of APLN
2014-08-30 13:41:07 -04:00
Idel Pivnitskiy
6a7fd374a2 Implemented LZ4 compression codec
Motivation:

LZ4 compression codec provides sending and receiving data encoded by very fast LZ4 algorithm.

Modifications:

- Added `lz4` library which implements LZ4 algorithm.
- Implemented Lz4FramedEncoder which extends MessageToByteEncoder and provides compression of outgoing messages.
- Added tests to verify the Lz4FramedEncoder and how it can compress data for the next uncompression using the original library.
- Implemented Lz4FramedDecoder which extends ByteToMessageDecoder and provides uncompression of incoming messages.
- Added tests to verify the Lz4FramedDecoder and how it can uncompress data after compression using the original library.
- Added integration tests for Lz4FramedEncoder/Decoder.

Result:

Full LZ4 compression codec which can compress/uncompress data using LZ4 algorithm.
2014-08-14 15:05:57 -07:00
Trustin Lee
5c24ca2216 Reduce the execution time of maven-antrun-plugin
Related issue: #2508

Motivation:

The '<exec/>' task takes unnecessarily long time due to a known issue:

- https://issues.apache.org/bugzilla/show_bug.cgi?id=54128

Modifications:

- Reduce the number of '<exec/>' tasks for faster build
- Use '<propertyregex/>' to extract the output

Result:

Slightly faster build
2014-08-13 15:45:00 -07:00
Idel Pivnitskiy
2b37b692d8 Implemented LZF compression codec
Motivation:

LZF compression codec provides sending and receiving data encoded by very fast LZF algorithm.

Modifications:

- Added Compress-LZF library which implements LZF algorithm
- Implemented LzfEncoder which extends MessageToByteEncoder and provides compression of outgoing messages
- Added tests to verify the LzfEncoder and how it can compress data for the next uncompression using the original library
- Implemented LzfDecoder which extends ByteToMessageDecoder and provides uncompression of incoming messages
- Added tests to verify the LzfDecoder and how it can uncompress data after compression using the original library
- Added integration tests for LzfEncoder/Decoder

Result:

Full LZF compression codec which can compress/uncompress data using LZF algorithm.
2014-07-17 07:18:53 +02:00
Trustin Lee
93a265ed0a Add missing m2eclipse life cycle mapping
Also, use ignore instead of execution because those plugins are not
really useful when building from Eclipse anyway.
2014-07-06 16:53:42 +09:00
Trustin Lee
330404da07 Fix most inspector warnings
Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile

Result:

Cleaner code
2014-07-02 19:04:11 +09:00
Trustin Lee
bb9ebb4bd0 Upgrade JACOCO to the latest version
.. to fix the build errors triggered by the old JACOCO release
2014-06-27 17:24:05 +09:00
Trustin Lee
eff05c439e Enable verbose:gc only when 'leak' profile is disabled
The leak profile generates a lot of garbage which makes the verbose:gc
output too large.
2014-06-27 17:09:18 +09:00
Idel Pivnitskiy
daa58f74e7 Implement a Bzip2Decoder
Motivation:

Bzip2Decoder provides receiving data compressed in bzip2 format.

Modifications:

Added classes:
- Bzip2Decoder
- Bzip2Constants
- Bzip2BlockDecompressor
- Bzip2HuffmanStageDecoder
- Bzip2MoveToFrontTable
- Bzip2Rand
- Crc32
- Bzip2DecoderTest

Result:

Implemented and tested new decoder which can uncompress incoming data in bzip2 format.
2014-06-24 14:49:49 +09:00
Mousom Dhar Gupta
9325b9121c Add MQTT protocol codec
MQTT is a open source protocol on top of TCP which is widely used in
mobile communication and also for IoT (Internet of Things) today. This
will add an open source implementation of MQTT so that it becomes easier
for Netty users to implement an MQTT application.

For more information about the MQTT protocol, read this:

http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
2014-06-21 16:51:37 +09:00
Trustin Lee
f4d6970e87 Move haproxy codec to a separate module 2014-06-21 15:58:53 +09:00
Phil.Baxter
b7f591c38a export sun security packages as optional 2014-06-15 21:01:20 +02:00
Norman Maurer
805ba157e4 DNS codec for Netty which is based on the work of [#1622].
Motivation:
As part of GSOC 2013 we had @mbakkar working on a DNS codec but did not integrate it yet as it needs some cleanup. This commit is based on @mbakkar's work and provide the codec for DNS.

Modifications:
Add DNS codec

Result:
Reusable DNS codec will be included in netty.

This PR also includes a AsynchronousDnsResolver which allows to resolve DNS entries in a non blocking way by make use
of the dns codec and netty transport itself.
2014-06-10 09:47:25 +02:00
Sergey Skachkov
d19d12511a Initial STOMP protocol work from @sskachkov 2014-06-04 17:09:11 +09:00
Trustin Lee
5be069f92d Require Maven 3.1.1 or above
.. because the build fails with an older Maven version due to Eclipse
Aether issues
2014-06-04 03:12:28 +09:00
Trustin Lee
d54030266b Upgrade to netty-tcnative 1.1.30.Fork2 to support Windows 2014-05-28 10:55:52 +09:00
Trustin Lee
e044fc3e56 Upgrade os-maven-plugin to fix an issue with IntelliJ IDEA on Windows 2014-05-27 04:41:58 +09:00
Trustin Lee
7667a4a32e Use a forked exec-maven-plugin instead of maven-antrun-plugin
Motivation:

maven-antrun-plugin does not redirect stdin, and thus it's impossible to
run interactive examples such as securechat-client and telnet-client.
org.codehaus.mojo:exec-maven-plugin redirects stdin, but it buffers
stdout and stderr, and thus an application output is not flushed timely.

Modifications:

Deploy a forked version of exec-maven-plugin which flushes output
buffers in a timely manner.

Result:

Interactive examples work.  Launches faster than maven-antrun-plugin.
2014-05-23 20:03:14 +09:00
Trustin Lee
3f8194557b Clean up the examples
Motivation:

The examples have not been updated since long time ago, showing various
issues fixed in this commit.

Modifications:

- Overall simplification to reduce LoC
  - Use system properties to get options instead of parsing args.
  - Minimize option validation
  - Just use System.out/err instead of Logger
  - Do not pass config as parameters - just access it directly
  - Move the main logic to main(String[]) instead of creating a new
    instance meaninglessly
    - Update netty-build-21 to make checkstyle not complain
  - Remove 'throws Exception' clause if possible
- Line wrap at 120 (previously at 80)
- Add an option to enable SSL for most examples
- Use ChannelFuture.sync() instead of await()
- Use System.out for the actual result. Use System.err otherwise.
- Delete examples that are not very useful:
  - applet
  - websocket/html5
  - websocketx/sslserver
  - localecho/multithreaded
- Add run-example.sh which simplifies launching an example from command
  line
- Rewrite FileServer example

Result:

Shorter and simpler examples.  A user can focus more on what it actually
does than miscellaneous stuff.  A user can launch an example very
easily.
2014-05-23 16:58:47 +09:00
Trustin Lee
3e8c80a26f Use maven-antrun-plugin instead of exec-maven-plugin
Motivation:

exec-maven-plugin does not flush stdout and stderr, making the console
output from the examples invisible to users

Modification:

Use maven-antrun-plugin instead

Result:

A user sees the output from the examples immediately.
2014-05-22 18:53:09 +09:00
Trustin Lee
e167ec51eb Add unified NextProtoNego extension support to SslContext
Motivation:

- OpenSslEngine and JDK SSLEngine (+ Jetty NPN) have different APIs to
  support NextProtoNego extension.
  - It is impossible to configure NPN with SslContext when the provider
    type is JDK.

Modification:

- Implement NextProtoNego extension by overriding the behavior of
  SSLSession.getProtocol() for both OpenSSLEngine and JDK SSLEngine.
  - SSLEngine.getProtocol() returns a string delimited by a colon (':')
    where the first component is the transport protosol (e.g. TLSv1.2)
    and the second component is the name of the application protocol
- Remove the direct reference of Jetty NPN classes from the examples
- Add SslContext.newApplicationProtocolSelector

Result:

- A user can now use both JDK SSLEngine and OpenSslEngine for NPN-based
  protocols such as HTTP2 and SPDY
2014-05-21 17:21:18 +09:00
Trustin Lee
66d969b453 Fix a build problem with JDK 8
Motivation:

Build fails with JDK 8 because npn-boot does not work with JDK 8

Modifications:

Do not specify bootclasspath when on JDK 8

Result:

Build is green again.
2014-05-20 22:37:55 +09:00
Trustin Lee
59f3d550fe Fix a problem where all classes are compiled again
Motivation:

Due to a known problem[1] of maven-compiler-plugin, our build always
compiles everything from scratch, which is waste of time.

Modifications:

Exclude package-info.java from the source list.

Result:

Much shorter build time.

[1]: https://jira.codehaus.org/browse/MCOMPILER-205
2014-05-20 20:04:41 +09:00
Trustin Lee
b27fd634f5 Clean up example execution
Motivation:

- example/pom.xml has quite a bit of duplication.
- We expect that we depend on npn-boot in more than one module in the
  near future. (e.g. handler, codec-http, and codec-http2)

Modification:

- Deduplicate the profiles in example/pom.xml
- Move the build configuration related with npn-boot to the parent pom.
- Add run-example.sh that helps a user launch an example easily

Result:

- Cleaner build files
- Easier to add a new example
- Easier to launch an example
- Easier to run the tests that relies on npn-boot in the future
2014-05-20 19:46:19 +09:00
Trustin Lee
46c79422ab Update os-maven-plugin again to address an IDEA integration issue 2014-05-19 01:32:31 +09:00
Trustin Lee
998afe09bf Upgrade os-maven-plugin to fix the build issue 2014-05-18 17:30:29 +09:00
Trustin Lee
a72230061d Add an OpenSslEngine and the universal API for enabling SSL
Motivation:

Some users already use an SSLEngine implementation in finagle-native. It
wraps OpenSSL to get higher SSL performance.  However, to take advantage
of it, finagle-native must be compiled manually, and it means we cannot
pull it in as a dependency and thus we cannot test our SslHandler
against the OpenSSL-based SSLEngine.  For an instance, we had #2216.

Because the construction procedures of JDK SSLEngine and OpenSslEngine
are very different from each other, we also need to provide a universal
way to enable SSL in a Netty application.

Modifications:

- Pull netty-tcnative in as an optional dependency.
  http://netty.io/wiki/forked-tomcat-native.html
- Backport NativeLibraryLoader from 4.0
- Move OpenSSL-based SSLEngine implementation into our code base.
  - Copied from finagle-native; originally written by @jpinner et al.
  - Overall cleanup by @trustin.
- Run all SslHandler tests with both default SSLEngine and OpenSslEngine
- Add a unified API for creating an SSL context
  - SslContext allows you to create a new SSLEngine or a new SslHandler
    with your PKCS#8 key and X.509 certificate chain.
  - Add JdkSslContext and its subclasses
  - Add OpenSslServerContext
- Add ApplicationProtocolSelector to ensure the future support for NPN
  (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on
  the client-side.
- Add SimpleTrustManagerFactory to help a user write a
  TrustManagerFactory easily, which should be useful for those who need
  to write an alternative verification mechanism. For example, we can
  use it to implement an unsafe TrustManagerFactory that accepts
  self-signed certificates for testing purposes.
- Add InsecureTrustManagerFactory and FingerprintTrustManager for quick
  and dirty testing
- Add SelfSignedCertificate class which generates a self-signed X.509
  certificate very easily.
- Update all our examples to use SslContext.newClient/ServerContext()
- SslHandler now logs the chosen cipher suite when handshake is
  finished.

Result:

- Cleaner unified API for configuring an SSL client and an SSL server
  regardless of its internal implementation.
- When native libraries are available, OpenSSL-based SSLEngine
  implementation is selected automatically to take advantage of its
  performance benefit.
- Examples take advantage of this modification and thus are cleaner.
2014-05-18 02:33:26 +09:00
Trustin Lee
942db3aa23 Preparation for porting OpenSSL support in 3.10
- Add licenses and dependencies
2014-05-17 20:01:09 +09:00
Trustin Lee
8a1cb40398 Fix the life cycle mapping problem with m2e
Motivation:

It should be frictionless to import our project into Eclipse

Modifications:

Exclude the plugins with missing life cycle mapping. They are not useful
for use with IDE anyway.

Result:

Fixes #2488
Netty is imported into Eclipse without a problem.
2014-05-12 21:35:13 +09:00
Trustin Lee
22a21cf54e Update netty-build to version 20
- Preparation for merging OpenSslEngine work
2014-05-08 09:59:18 +09:00
Trustin Lee
724aed4757 Generate the default JAR to make oss.sonatype.org happy
Motivation:

oss.sonatype.org refuses to promote an artifact if it doesn't have the
default JAR (the JAR without classifier.)

Modifications:

- Generate both the default JAR and the native JAR to make
  oss.sonatype.org happy
- Rename the profile 'release' to 'restricted-release' which reflects
  what it really does better
- Remove the redundant <quickbuild>true</quickbuild> in all/pom.xml
  We specify the profile 'full' that triggers that property already
  in maven-release-plugin configuration.

Result:

oss.sonatype.org is happy.  Simpler pom.xml
2014-05-03 17:28:28 +09:00
Trustin Lee
eb46726c52 Enforce the release is performed only from RHEL 6.5 or equivalent
Motivation:

Netty must be released from RHEL 6.5 x86_64 or compatible so that:

1) we ship x86_64 version of epoll transport officially, and
2) we ensure the ABI compatibility with older GLIBC versions.
   The shared library built on a distribution with newer GLIBC will not
   run on older distributions.

Modifications:

- When 'release' profile is active, perform an additional check using
  maven-enforcer-plugin so that 'mvn release:*' fails when running on
  non-RHEL6.5.  This rule is active only when releasing, so a user
  should not be affected.
- Simplify maven-release-plugin configuration by removing redundant
  profiles such as 'linux'.  'linux' is automatically activated when
  releasing because we now enforce the release occurs on linux-x86_64.
- Remove the no-osgi profile, which is unused
- Remove the reference to 'sonatype-oss-release' profile in all/pom.xml,
  because we always specify 'release' profile when releasing
- Rename the profile 'linux-native' to 'linux' for brevity
- Upgrade oss-parent and maven-enforcer-plugin

Result:

No one can make a mistake to release Netty on an environment that can
produce incompatible or missing native library.
2014-05-02 21:17:09 +09:00
Trustin Lee
3f57df1763 Upgrade os-maven-plugin to fix a build issue on windows-x86_32 2014-05-02 21:14:54 +09:00
Trustin Lee
68b4c9f2b5 Simplify native library resolution using os-maven-plugin
Motivation:

So far, we used a very simple platform string such as linux64 and
linux32.  However, this is far from perfection because it does not
include anything about the CPU architecture.

Also, the current build tries to put multiple versions of .so files into
a single JAR.  This doesn't work very well when we have to ship for many
different platforms.  Think about shipping .so/.dynlib files for both
Linux and Mac OS X.

Modification:

- Use os-maven-plugin as an extension to determine the current OS and
  CPU architecture reliable at build time
- Use Maven classifier instead of trying to put all shared libraries
  into a single JAR
- NativeLibraryLoader does not guess the OS and bit mode anymore and it
  always looks for the same location regardless of platform, because the
  Maven classifier does the job instead.

Result:

Better scalable native library deployment and retrieval
2014-05-02 04:21:29 +09:00
Jens Reimann
b88c7d6f9a Mark sun.nio.ch as optional
Motivation:

If sun.nio.ch is not optional this will cause troubles in the
OSGi world. The package is not exposed by default in OSGi, so
actually the whole netty framework cannot be used directly.

There are workarounds, but workarounds are ugly. Especially since
the use of sun.nio.ch is optional. So the requirement on the
package should be optional as well.

Modifications:

Make the import of sun.nio.ch optional.

Result:

If the package cannot be imported it will behave as if the package
sun.nio.ch is not present (like with other JVMs). If the package is
exposed in OSGi (e.g. bootclassloader delegation, extension fragment)
it will be used.
2014-04-23 10:37:39 +02:00
nmittler
754e08796b First cut of frame encoding/decoding and session management for HTTP2
Motivation:

Needed a rough performance comparison between SPDY and HTTP 2.0 framing.
Expected performance gains were seen in HTTP 2.0 due to header
compression.

Modifications:

Added a new codec-http2 module containing all of the new source and unit
tests.  Updated the top-level pom.xml to add this as a child module.

Result:

Netty will have basic support for HTTP2.
2014-03-27 10:40:47 -07:00
Trustin Lee
3030541844 Add -verbose:gc option for test runs
Motivation:

While investigating the recent CI machine crashes, I observed that the
JVM processes spawned by surefire sometimes take up to 1 GiB RAM.
Consuming large amount of memory isn't really a problem, but we need to
make sure no GC trashing is occuring during the tests.

Modifications:

Add -verbose:gc option to the test JVM arguments

Result:

We can determine if there is any GC anomalies going on in our CI
machine.
2014-03-17 14:20:18 +09:00
Norman Maurer
b10b79b455 Remove sniffer whitelist entries for NIO.2
Motivation:
Cleanup pom.xml file.

Modifications:
Remove sniffer whitelist entries for NIO.2 as we not include a NIO.2 bases transport anymore.

Result:
Less entries in pom.xml
2014-03-13 07:03:29 +01:00
Norman Maurer
77295c1230 [#2308] Use SelectorProvider.open*() to open NIO channels and so remove condition when create new NIO channels.
Motivation:
At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our
NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which
uses synchronized internal. This change removed the bottleneck.

Modifications:
Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and
SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation.

Result:
Less conditions when create new channels.
2014-03-13 07:03:20 +01:00