Further improvements

[MrMage]

I might not have time to do all of these, but I figured it would make sense to list them here:

Implementation:

• Migrate to Swift 4
• Improve iOS compatibility
• ServerCancellingTests.testServerCancelsUnary and ServerTimeoutTests.testTimeoutUnary still emit ServerSessionUnaryBase.run error sending response: unknown; we should avoid sending responses when the call has been cancelled anyway. (For that, we would need to know when the call has been cancelled, probably by listening for a receiveCloseOnServer operation.)
• Check for memory leaks caused by calling grp_strdup without freeing the result. — might be fixed by Fix a few memory leaks related to unreleased slices in observers and metadata arrays #217 (see also Add channel arguments #199 (comment))
• Fix a potential memory leak of grpc_channel_credentials in cgrpc_channel_create_secure.
• Improve concurrency and handling of closing calls (Call message queue cannot be closed safely #19).
• Look into deallocating (and thus draining) completion queues on a background thread (see Channel gets deinitialized on main thread #96)
• Consider providing the status code with a unary call to fix Consider throwing an error on non-success status code in unary call #88.
• Check whether we are leaking server address/certificate or metadata string slices etc.
• Avoid throwing in ServerSession....run() — instead catch and log errors and send an error status to the client (might be obsolete)
• Unify all the ServerSession....run() calls as much as possible; at least the error reporting is identical every time.
• Convert ServiceServer to a plug-in architecture: Initialize it with any number of ...Server implementations that can announce what methods they'd like to respond to. (This is easier than it sounds — essentially, we'd just stop e.g. Echo_EchoServer from subclassing ServiceServer and instead have it provide a list of methods it responds to. This would let us serve multiple services on the same port.
• Ensure that the server is going to tell us once it is pointless to send responses because the call has timed out (or been cancelled for other reasons). We don't want the server to keep sending stuff because it doesn't know that the connection has been terminated already. (Also needs tests.)
• Move the CFlags specified in the Makefile into Package.swift.
• Ensure better completion queue shutdowns:
• - Shut down even when handler.close...() throws
• - Augment the documentation to say that close() does not need to be called if the handler throws
• - Check that canceling a call (both server- and client-side) also shuts down its completion queue
• Ensure that we conform to the standard gRPC status codes as far as possible (Ensure that gRPC ObjC implementation conforms to standard status codes in gRPC grpc#5994). Most of those are either in the underlying C code are unapplicable for us, though.
• Investigate O(n^2) performance described in O(n^2) message queue #27.
• Investigate Too coarse callMutex. #26.
• Fix the remaining error cases in Robust error handling #10.
• Pass gRPC interoperability tests (Pass gRPC interoperability tests. #3).
• Fix make clean recursive call when directory does not exist #193.
• Make it more clear how to close a channel (How do I close the connection? #198), and investigate whether our calls should keep a strong reference to the channel, to keep the channel open until the call finishes.
• Change the tests discussed in Two important fixes (and possibly more improvements) #188 to mention that sending a non-OK response can drop messages (see Dropped response messages when sending non-OK status code grpc#14842 (comment) and https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/grpc-io/OwZZq27awUQ/uNRL0_7ICQAJ).
• Avoid requesting the status from the server when starting a server-unary request — instead request the status when we receive a response message as well.
• Make test stubs call the callback they were started with.
• For the few print calls that remain, add the option to specify a custom logger object.
• Remove Session.initialMetadata/.trailingMetadata or make it useful.
• Add the option to specify custom root certificates (e.g. for certificate pinning).

Extra tests:

• Test what happens when sending many parallel requests (50, 100, 200, 500?) at once. My suspicion is that the dispatch queue won't spawn more than ~64 threads, so we might run into problems there. Should be fixed now that we spawn individual threads.
• Track the number of allocations/deallocations (including gRPC calls/completion queues/handlers etc.!) and thread start/stops in tests, to ensure that we are not leaking objects/threads.
• Test not closing the channel at all (should probably just time out), both server and client side. (This might be redundant with the existing timeout-tests.)
• Look into porting over some integration tests provided by the Java library (Integration Test Parity with Java grpc - for consideration #48).
• Add tests to check for memory leaks (see https://github.com/apple/swift-nio/blob/68db2325dfdbed2ec6f8c70c9c7b4ba97876dfce/IntegrationTests/tests_04_performance/test_01_resources/README.md).

Contributions are welcome :-)

[pontus-andersson]

@MrMage Is this list up to date? Do we have any updates on certificate pinning?

[MrMage]

@MrMage Is this list up to date? Do we have any updates on certificate pinning?

This list will be obsolete once we ship the SwiftNIO version. You might be able to use the SwiftNIO version with certificate pinning; @glbrntt might be able to help with that.

[MrMage]

The CgRPC implementation is now officially deprecated; closing this for now.