API Support Forum
User Profile

Viewing User Profile for: WWatson2582


About

May 03, 2018 04:49 PM

Jul 09, 2021 08:36 AM

Jul 12, 2021 10:57 AM



Post Statistics
WWatson2582 has contributed to 38 posts out of 5573 total posts (0.68%) in 2146 days (0.00 posts per day).

20 most recent posts:

API Support » Socket errors Jul 09, 2021 @ 08:36 AM (Total replies: 9)

I now have a second client reporting the same "socket errors" causing disconnection. Notably, once this error occurs, they are often unable to reconnect as the server sends a "user already connected" rejection message. I have both users contact GAIN account and contact details - please let me know how to forward them to you so you can follow up with them and hopefully get this solved.

I am not seeing any consistency in their actions causing the socket errors - they appear to happen randomly without any particular user action, without regard to data flow or market speed. They are both using the latest released COM API version (4.0.3.58). Typically all we see from the logging mechanism is something like this:

07/08/2021 11:33:13 - OnDisconnected(): Disconnected: reason [Socket error]

API Support » Socket errors Apr 29, 2021 @ 08:40 AM (Total replies: 9)

By the way, when he gets a socket error, the OnDisconnected event is called in our code with reason containing DisconnectionReason_SocketError and reason containing "Socket error" and that's all we apparently have to work with.

Is there any API settings we can twiddle that would make his connection more tolerant to momentary local disconnects or timeouts?
Edited by WWatson2582 on Apr 29, 2021 08:42 AM

API Support » Socket errors Apr 29, 2021 @ 08:30 AM (Total replies: 9)

Good morning, Chris:

His ports 9210 and 9211 are working - this is not a case of unable to connect - it runs for a while and then randomly disconnects. GAIN's is the only server he is reporting having problems with, and he is our only client reporting this sort of problem. Here is his latest response to me:

--------------
I continue to have IRT problems disconnecting from Gain. It remains random, maybe 6-12x a day. Today not a single drop until 11:07 then about 6x in the afternoon.
1. Ports 9210 and 9211 are working. Attached is the netstat log file that shows IRT and Gain IP and Port addresses. Feel free to forward it to Gain. It shows Gain ("trader.exe") and Investor RT connected to Gain IP 66.76.151.30 through Port 9210 and 9211.
2. Per Gains instructions, I ran ping test on 173.219.221.161 and 64.74.108.94 without any issues. No drops and RT times around 30ms.
3. I ran tracert to prod.gainfutres.com and got 12 hops to suddenlink.net (per Gains instructions.) I did get a bunch of timeouts after reaching suddenlink,net but I don't think that matters.

---------------------
He forwarded to us a file containing netstat results that appears unremarkable.

Where is the "API Log" located? Is there one created internally by the COM API or is this something the COM API client (us) are supposed to be maintaining through (for example) API events like OnErrorOccurred?

API Support » Socket errors Apr 26, 2021 @ 08:14 AM (Total replies: 9)

We have a client that reports having many socket error disconnections with GAIN COM API and did not have them with previous API. Is there a way we can diagnose this further or should he contact GAIN support directly for this?

API Support » GAIN API COM uuid change? Feb 24, 2021 @ 09:37 AM (Total replies: 2)

Thanks, Chris!

API Support » GAIN API COM uuid change? Feb 24, 2021 @ 09:15 AM (Total replies: 2)

Will the UUID we were issued for the older OEC API still work with all GAIN servers for the GAIN API COM? We have one beta tester who is trading on the live server and everything is working and a different user that reports that when he tries to connect, he gets a connection failure message with the reason "User software is not allowed to connect." Not sure what to tell them about this. We seem to have everything working now and should have our conformance spreadsheet to you in a matter of days.

API Support » OSO orders bug in COM API Feb 24, 2021 @ 09:10 AM (Total replies: 12)

We're working now fine, so you can consider this issue closed. Thanks!

API Support » OSO orders bug in COM API Feb 19, 2021 @ 09:50 AM (Total replies: 12)

I'm not sure I understand why reporting non-existent orders to the client is a "feature", but I have worked around this by filtering out all orders whose "comments" field starts with "Sub order for" and things seem to be working fine on our end now. I know that according to your description I am technically filtering out the real order and holding on to the fake order, but for our purposes it works out and I see no way to otherwise distinguish real from fake.

So I guess my remaining question is: why are these fake orders coming through the API at all? What possible use could I on the client end have for them?
Edited by WWatson2582 on Feb 19, 2021 09:51 AM

API Support » COM API version disparity Feb 18, 2021 @ 10:04 AM (Total replies: 3)

Not sure how this got posted twice but I'd appreciate it if a moderator could delete one or the other!

API Support » COM API version disparity Feb 17, 2021 @ 10:34 AM (Total replies: 3)

Not sure if this was intended or not, but the latest COM API installers are titled "GAIN GFAPI COM 4.0.3.37.exe" and "GAIN GFAPI COM x64 4.0.3.37.exe" yet from the "GF.Api.COM.dll" version resource it is reported that they are in fact installing version 4.0.3.45

API Support » OSO orders bug in COM API Feb 11, 2021 @ 11:40 AM (Total replies: 12)

It wouldn't let me log in, Chris, so I guess I need a credential reset.

API Support » OSO orders bug in COM API Feb 11, 2021 @ 09:52 AM (Total replies: 12)

Do I understand that you are saying that the "fake" orders are never being filled? When are they cancelled and why do we even see them on the client side of the API if they are not "real"?
Edited by WWatson2582 on Feb 11, 2021 09:53 AM

API Support » OSO orders bug in COM API Feb 11, 2021 @ 09:52 AM (Total replies: 12)

I will investigate this further. How does one specify the server to use with the Gain Trader app? My credentials don't seem to work with anything other than api.gainfutures.com

API Support » OSO orders bug in COM API Feb 10, 2021 @ 04:21 PM (Total replies: 12)

I just heard that a customer of ours testing the COM API with our product had an bracket order go from LONG 3 to SHORT 3 because of this bug but fortunately caught it and were able to flatten their position manually. We are going to disable OSO orders until this is resolved, but this was a real money account so it appears the bug is not limited to the test server.

I would post screencaps of the entire transaction but don't see a way to do that here.

API Support » OSO orders bug in COM API Feb 10, 2021 @ 03:45 PM (Total replies: 12)

We've done this multiple times using our own software calling GFAPI()->Orders->SendOSOOrders() as well as the sample COM API code (modified as given in the first message) always with the same result.

The account is mine ("WWatson2582") using the test server api.gainfutures.com.

In my most recent test, the initial main order was 211862711 and the OCO bracket orders were 211862712 and 211862713. The additional incorrect orders were 211862714 and 211862715.

The net effect of these extra orders is that when the bracket order is supposed to flatten the position, it is instead left short or long depending on which side of the bracket is filled (both orders on that side are filled simultaneously.)

API Support » OSO orders bug in COM API Feb 05, 2021 @ 01:46 PM (Total replies: 12)

I have encountered the following bug in the COM API (latest released version).

After submitting a OSO order using GFAPI()->Orders->SendOSOOrders() method, the two linked orders are submitted twice, or in other words, are each duplicated twice. After the bracket order is completed and the position would normally be again flat, the duplicate order causes an extra closing transaction to be executed, often leaving a non-flat position.

I have created some sample code to demonstrate this using as a base your COM API sample application. All modifications are done to the file CppCOMSampleDlg.cpp. To demonstrate this bug:

1) Add the following global variable declaration to the top of the file:

double lastPrice;

2) Change the CCppCOMSampleDlg::OnPriceChanged method as follows:

void __stdcall CCppCOMSampleDlg::OnPriceChanged(GF_Api_COM::IGFComClientPtr client, GF_Api_COM::IContractPtr contract, GF_Api_COM::IPricePtr price)
{
lastPrice = price->LastPrice;

if(m_ShowPriceUpdates)
{
log Symbol PriceToString(price->LastPrice) LastVol << std::endl;
}
}

3) Change the CCppCOMSampleDlg::OnBnClickedSendorder() as follows:

void CCppCOMSampleDlg::OnBnClickedSendorder()
{
CheckConnectedGFAPI();
COrderDlg dlg(GFAPI());
bool orderError = false;

if(dlg.DoModal() == IDOK)
{

GF_Api_COM::IOrderDraftBuilderPtr builder;
builder.CreateInstance(__uuidof(GF_Api_COM::OrderDraftBuilder));
GF_Api_COM::IAccountListPtr accounts = GFAPI()->Accounts->Get();
GF_Api_COM::IAccountPtr account = accounts->GetAt(0);
GF_Api_COM::IAccountIDPtr accountID = account->id;

builder = builder
->WithAccountID(accountID)
->WithSide(dlg.m_Buy ? GF_Api_COM::OrderSide_Buy : GF_Api_COM::OrderSide_Sell)
->WithQuantity(dlg.m_Qty)
->WithContractID(GFAPI()->Contracts->Get_2((LPCSTR)dlg.m_SelectedContract)->id)
->WithOrderType((GF_Api_COM::OrderType)dlg.m_SelectedType)
->WithFlags(dlg.m_GTC ? GF_Api_COM::OrderFlags_GTC : GF_Api_COM::OrderFlags_None);

double tickSize = GFAPI()->Contracts->Get_2((LPCSTR)dlg.m_SelectedContract)->tickSize; // To set up bracket order distances later

GF_Api_COM::IOrderDraftPtr mainOrder = builder->Build();

if (GFAPI()->Orders->Drafts->Validate_2(mainOrder)->Count > 0) {
log << "Main Order has invalid parts and will not be sent" << std::endl;
orderError = true;
}

GF_Api_COM::IOrderDraftBuilderPtr target;
target.CreateInstance(__uuidof(GF_Api_COM::OrderDraftBuilder));

target = target
->WithAccountID(accountID)
->WithSide(GF_Api_COM::OrderSide_Sell)
->WithQuantity(dlg.m_Qty)
->WithContractID(GFAPI()->Contracts->Get_2((LPCSTR)dlg.m_SelectedContract)->id)
->WithOrderType(GF_Api_COM::OrderType_Limit)
->WithFlags(dlg.m_GTC ? GF_Api_COM::OrderFlags_GTC : GF_Api_COM::OrderFlags_None)
->WithPrice(lastPrice + 15 * tickSize);

GF_Api_COM::IOrderDraftPtr profitTarget = target->Build();

if (GFAPI()->Orders->Drafts->Validate_2(profitTarget)->Count > 0) {
log << "Profit Target Order has invalid parts and will not be sent" << std::endl;
orderError = true;
}

GF_Api_COM::IOrderDraftBuilderPtr loss;
loss.CreateInstance(__uuidof(GF_Api_COM::OrderDraftBuilder));
loss = loss
->WithAccountID(accountID)
->WithSide(GF_Api_COM::OrderSide_Sell)
->WithQuantity(dlg.m_Qty)
->WithContractID(GFAPI()->Contracts->Get_2((LPCSTR)dlg.m_SelectedContract)->id)
->WithOrderType(GF_Api_COM::OrderType_Stop)
->WithFlags(dlg.m_GTC ? GF_Api_COM::OrderFlags_GTC : GF_Api_COM::OrderFlags_None)
->WithPrice(lastPrice - 15 * tickSize);

GF_Api_COM::IOrderDraftPtr stopLoss = loss->Build();

if (GFAPI()->Orders->Drafts->Validate_2(stopLoss)->Count > 0) {
log << "Stop Loss Order has invalid parts and will not be sent" << std::endl;
orderError = true;
}

if (!orderError) {
GF_Api_COM::IOrderListPtr orders = GFAPI()->Orders->SendOSOOrders(mainOrder, profitTarget, stopLoss, GF_Api_COM::OSOGroupingMethod_ByFirstPrice);
if (!orders)
log << "Cannot send OSO orders" << std::endl;
else
log << "OSO Orders have been sent. " << std::endl
GetAt(0)->id->Value GetAt(0)->ToString << std::endl
GetAt(1)->id->Value GetAt(1)->ToString << std::endl
GetAt(2)->id->Value GetAt(2)->ToString << std::endl;
}
}
}

To demonstrate a bug with OSO orders after connecting to the GAIN server:
1) Subscribe to prices for a contract, e.g. ESH21
2) Click on the "Send Order" button in the main application dialog box.
3) Assure that the Order dialog box is completed with a Market Buy order for the same symbol subscribed to in step #1

An OSO bracket order will be constructed and submitted using a 15-tick Limit order and 15-tick Stop order. Rather than just the primary order and two linked orders submitted, you should see duplicate orders for each of the linked orders.

API Support » Wrong platform linked to new COM API release? Feb 04, 2021 @ 01:20 PM (Total replies: 2)

Can you verify that the newest COM API version released on this page:
https://gainfutures.com/gainfuturesapi/documentation/
linked to the "Download GF API (COM 64-bit)" button is actually a 64-bit version. I think the 32-bit version got cross-linked to both platform download buttons.

New Feature Requests » Developer Forum feature request Feb 04, 2021 @ 01:02 PM (Total replies: 1)

It would be useful if you had a topic somewhere in this forum that we can subscribe to and be automatically notified when you release updates, such as the recent release of the new COM API libraries.

API Support » GAIN API COM Installer quirk Jan 04, 2021 @ 08:58 AM (Total replies: 1)

When the GAIN GFAPI installer completes, the dialog box which offers the "Finish" button has a checkbox item that reads "Launch GAIN GFAPI COM [x64]" which appears to do absolutely nothing - perhaps it should launch some version info notes or am I missing something?

S.W.

API Support » GAIN API COM installation and version query Dec 30, 2020 @ 10:13 AM (Total replies: 3)

1) If we choose to use the supplied .exe to install the GAIN API COM components, is there a command line argument we can supply from our installer that will operate the GAIN API COM installer in "silent" mode (not requiring any user interaction)?

2) Must GAIN API COM components be installed to the C:\Program Files\GAIN folder (or its 32-bit equivalent) or can we install it to a folder of our own designation?

3) Is there an API call or other mechanism to see what version of the GAIN API COM components are currently installed? We issue a lot of updates and would rather not reinstall/re-register these components every time if the latest version is already installed.

Thanks for your replies!