Ported MtApi5 to .Net Core

[lazou]

This PR will add support for .Net Core on the client side (for MtApi5) as requested in #134. Contract files are linked from MtApiService to prevent duplicated code. Only duplicated some files due to required changes (unsupported functionality of the doftnet/wcf dependencies).

• added .net core based MtApiService (MtApiServiceNetCore)
• based on https://github.com/dotnet/wcf
• only client side is available in .Net Core
• piping removed, only tcp connection possible
• ported MtApi5 and MtApi5TestClient to .Net Core

[vdemydiuk]

@lazou Hi.
First of all I want to say thank you for your help in support MtApi.

I would like to ask you to change destination branch of PR to dev. I will review deep your changes and will try to merge it.

I have first remark: piping is using for local connection when user does not define IP address for connection. In my opinion, it must be more faster then using local TCP connection. If both connections have similar connection characteristics then we can use only one TCP and it will not be blocker for merging the PR.

[lazou]

Hi @vdemydiuk ,

I changed the target branch like requested to dev. In this PR the use case for using a local connection is still possible, I only call the basic ctor with localhost as IP. I used it now for around 4 months without any issues for normal trading and also for the tester. It could be possible that the tcp connection is not that fast as the piping one, but it was no requirement for me. But there is already a NamedPipeTransportBindingElement class within the dotnet wcf repo and obviously there will be piping support in the future (see TransportBindingElementImporter L153)

[KptKuck]

@lazou Hi.
First of all I want to say thank you for your help in support MtApi.

I would like to ask you to change destination branch of PR to dev. I will review deep your changes and will try to merge it.

I have first remark: piping is using for local connection when user does not define IP address for connection. In my opinion, it must be more faster then using local TCP connection. If both connections have similar connection characteristics then we can use only one TCP and it will not be blocker for merging the PR.

Maybe it helps for the decision to kick out pipes
https://stackoverflow.com/questions/10872557/how-slow-are-tcp-sockets-compared-to-named-pipes-on-windows-for-localhost-ipc

[vdemydiuk]

@KptKuck Thank you Christian for good link.
@lazou I will merge your PR soon. First I will make next release and then I will work on .Net Core adaptation.

[vdemydiuk]

@lazou After some discussions in telegram's chat I decided to postpone merging the PR into branch. Some users are using pipe mode and have comparative information that pipe is working faster.

[lazou]

@vdemydiuk Ok, no problem. Let`s see if the piping support will be added soon to the WCF library of .net core. I will try to keep the branch up to date.

[vdemydiuk]

@vdemydiuk Ok, no problem. Let`s see if the piping support will be added soon to the WCF library of .net core. I will try to keep the branch up to date.

@lazou Thank you very much.

[eabase]

@vdemydiuk
Slightly OT, but...

After some discussions in telegram's chat I decided to postpone merging the PR into branch. Some users are using pipe mode and have comparative information that pipe is working faster.

Is piping also available in the Python API? If so, how is the connection set when not specifying IP, like here:

client = mt.MtApiClient()
...
client.BeginConnect(ip, port)

---

UPDATE
Ok, I think I got it. Not sure how to implement it though.
Seem like this might be the correct way (??)...

client = mt.MtApiClient()
...
# To use a TCP based (host:port) connection:
client.BeginConnect(ip, port)

# To use a pipe based (port only?) connection:
# (Note: a named pipe port is located on the `localhost` interface.)
client.BeginConnect(port)

[KptKuck]

There is no Python-API
Python loads the .NET Assambly MtApi5.dll via the package pythonnet

[KptKuck]

OT ...

[vyacheslav-skvortsov]

HI!
Do you have any updates on this PR?

[lazou]

@vyacheslav-skvortsov Updates in which regard? Merging it into dev or updating this branch to newer dependency versions? You can already use this .net port by compiling the sources of this branch at your end. I think not that this PR will be merged in the next couple of months since @vdemydiuk is obviously not active or has no time anymore.
I am using this .net port quite some time now without any issues.

[supermomonga]

@vdemydiuk

After some discussions in telegram's chat I decided to postpone merging the PR into branch. Some users are using pipe mode and have comparative information that pipe is working faster.

I believe the WCF library (https://github.com/dotnet/wcf) already officially supports Named Pipe. So, is it possible to merge this Pull Request now?

[lazou]

Hi @supermomonga, I tested the named pipes some months ago (when at preview stage), but was not impressed by the performance. This was the PR I used: lazou#21. But maybe I did something wrong 😉

[supermomonga]

@lazou Thanks, I'll check it!