Topic: Do you use a bot for trading? - page 6. (Read 17845 times)

In my opinion, asynchronous api is much better overall

Though it may be harder to code since you have to keep track of the requests that you made internally. As I said, I worked with proprietary api's, and they specifically distinguish between asynchronous and synchronous modes of operation in the sense I mean it (that's basically how such modes are defined). Below is the relevant part which I copied from the developer's guide of one them (namely, quik trading api):


You can use Google Translate, but this piece essentially says that there are two modes of sending transactions, i.e. synchronous and asynchronous. In the former case (synchronous mode), the calling function waits for the reply from the server, while in the latter case (asynchronous mode), the function exits immediately and the reply is received through a callback function. The emphasized part repeats what I said before, i.e. synchronous transactions can be sent only sequentially after receiving a reply from the previous request. As I remember, the guide specifically mentions that if you try to send another synchronous transaction (say, from another thread) while still waiting for a reply, the behavior is undefined. I tried that, and it just crashed the dll library which was used for transacting (trans2quik.dll if you are curious)

Yay okay. As you said, there are different ways of implenting stuff on the client side. Synchronous calls, sending a request and waiting for
the response. and so on. Sending the request and asynchronously waiting for the response. So far we do agree Just different styles
of implementation. Indeed all the exchange API's I know so far are implementing simple request/response pattern. But thats a different topic
and not the point where the discussion started.

@deisik brought up this BTer async thing And I do not plan to implement BTer so I don't care about the behaviour that much. have
some thoughts on my own, but that is just speculating how they implemented their API.

PS: lost 3hours I could spend in coding 

But my discussion was on Client HTTP <-> API layer.
So we lost time all of us. Good 

I've never have seen a 202 response code either.

And maybe I pushed the discussion to the wrong side: the client-side.
For me the more interesting part is the BTer server-side
and the behaviour @deisik described. Still thinking about what he said

PS: Despite all a nice discussion so far

I think i have the DEFINITIVE Reponse.
I remember about http return codes.

When CALL Is Synchronous you get HTTP 200
When CALL Is Asynchronous you get HTTP 202 (because it only means accept)

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

As i remember i never seen something different than HTTP 200 after the REST Connection 

To come back to the topic  

Yes, I tried several bots in the past and this made me the decisson the implement my own trading platform. I'm not talking
of a "bot" anymore.

Each bot I tried, had its issues and parts I wanted to improve: different strategies, faster execution, diving into new technologies etc.
Here's a list of bots I tried:
- C.A.T.  
- SpreadBot (a German project)
- leoArdo
- poloniexlendingbot
- currently having a close look how gunbot is performing
- and some github open source projects I forgot


 

Of course, this is async at APPLICATION LEVEL.
This is an high level library but i can also write that function by mystelf

- Prepare Call
--------- NEw Thread(PerformCall -> Give the Reponse to Method X)
- Continue with main flow

I use java futures for dedicated process like monitoring or checking running algorithms.

But if we look into NEw Thread(PerformCall -> Give the Reponse to Method X) we will discover that a Sync call is happening :-) It's invisible to you, but technically is a Sync call.

There's a lot of mysunderstanding about the concept of Sync/Async because many time it depends by the level of the view.
The code you post is surely async but the real http call will be performed in sync way.

A REAL async http Call is this :



As you can see 1-2 is the SEND Routine (that can be completed with a 200 http OK Code)
Then 3-4 is the real async response, where you set a service for the response.

The question is not about multithreading

The question is about exchange api's and how they work in practice, surely not about how exactly your code can send requests. These gory details are ultimately irrelevant for most practical reasons since this is not where problems typically arise. With a synchronous api, you can't possibly do that (remember I've been there), and it doesn't matter if you are using a true multithreading or just software interrupts (or whatever) since you will most likely just receive an error from the exchange if you try that (this refers only to authenticated requests). But you seem not to understand that

hm.... might mixing things up of the transport layer, the protocol layer and how an exchange API is implemented.
For sure there is a connection established when I want to invoke the API. But the http requests and responses do not have
to be synchronous.

There are tons of simple examples of working with REST Api's in a asynchronous way, e.g.:

Future response1 = client.target("https://bittrex.com/api/v1.1/market/cancel")
                               .request()
                               .async().get(Response.class);

Future response2 = client.target("https://bter.com/api/1/private/cancelorder")
                               .request()
                               .async().get(Response.class);

// now you can do other stuff or sit and wait till you have both responses.

You are totally right and same in java. I'm doing my stuff in exactly the same way

Yeah this is multithreading.
You didn't explain me how did you get the response result from the server. I'm interested in.
Then i will use your response to demostrate you that HTTP <-> API will remain sync 

No Misunderstanding from my point of view. Because i'm not talking about internal exchange code or internal client code. I'm talking about (since the beginning) of CLIENT CALL HTTP <-> APISYSTEM.
CLIENT CALL HTTP = A Class inside your Client, that will send the Data over the net using http/tcpip protocol.

The async call you are talking about are async not at HTTP Level but at Application Level.
There's nothing to misunderstand. In all the examples you wrote, CALLS Are sync.

You can have

CLIENT <- ASYNC -> DELEGATE HTTP CALL <- SYNCH -> API SYSTEM <- ASYNC -> INTERNAL API ROUTINE

The red part will be always sync.

Do you know how to make this call DELEGATE HTTP CALL <- SYNCH -> API SYSTEM <- ASYNC async?
You need to open a service on your machine and let the Exchange reply on that service. But it doesn't works this way, so to get data from exchange you must use HTTP REST SYNC CALL.

It means CLIENT -> HTTP CALL -> ASYNC -> API SYSTEM -> RESPONSE ON CLIENT ADDRESS:PORT SERVICE

This is async.
When you'll find a system that works this way, we will talk about async call.  

It's very funny we are technicall talks about sync/async call in a topic called Do you use a bot for trading?  

This is called an asynchronous mode of operation

There is no problem with that since no one forces you to use this mode. If you need to wait for a reply, you just wait for it, and that's pretty much all there's to it. I don't know how it is done in Java (since I'm mostly developing on C++) but you can tell which reply refers to which request, so there is no problem either if you want to use api asynchronously. For example, you can send a new order request and at the same time, without waiting for a reply to this request, send a few other requests cancelling a bunch of other orders. For example, with Bitfinex api you can easily cancel a few orders with just one request, if I remember correctly (I don't use this exchange for over a year already), but at other exchanges (e.g. at Exmo) you have to cancel each order individually and wait till your cancellation request gets executed. Otherwise, you will receive an error if you just send a bunch of authenticated requests simultaneously

I think there was a lot of misunderstanding in the last couple of posts from both sides

The same point I didn't get: How do you know, if bter is internally working async or sync. This is not visible to a client. And  I don't care how they work internaly, as long as they are
fast and reliable. You already said it... If bter accepts a request with a higher nonce before a lower nonce . something ist not working as it should in my opinion.

@deisik but it is an interesting way, to work with the bter private  API. thanks for the hint. besides that, nearly every exchange has some undocumented stuff hidden in their API.

hmmm.... you may be mixing things up. But I dunno want to start a new discussion.
People might have different definitions of sync, async, threads, callbacks ,etc.

The point is,  that some steps in order execution must be done in a sequence, and other steps could be
done asynchron and parallel. It's all about optimization. (order execution is a sub-optimal example)

Most API's do have a roundtrip of about 500ms to 1s or even more.  e.g. If you now want to check e.g. market summaries of 150 altcoins hat polo,
you can do this in a loop and your done in about max 150s. Or you can fire 150 requests in parallel with some kind of client side rate limiting to not
exceed 6 req/sec. (no im not doing it in that way just an example)  and subscribe to the results. The rate limiter is aware of backpreassure
so, between firing the request and the response might be a long time. you won't block any thread. but in the total you have all the results in a
much shorter time.

And your are totally right with "good programming practise makes you decide about what to use". agree to that.

To answer your question what my program is doing: Crunching and analyzing a shit load of data

Well, this is not exactly so, but that's not my point

Synchronous (and asynchronous) here doesn't mean that you have (or don't have) to wait for a reply being stuck in a loop. Synchronous essentially means that you have to wait for a reply before you can send an authenticated (mind that) request again (this apparently has nothing to do with any client libraries whatsoever). In other words, you have to synchronize your requests with exchange replies. If trading api is synchronous as is the case with most exchanges out there, you can't send a new request without having received the reply from the exchange (i.e. without your previous authenticated request having been processed by the exchange). If you just send a new request, no matter what, you will get an error. If some dude is claiming that he has deep understanding of real exchanges' api's (note that I don't mention any bots here and neither did I say a word about them before in this respect since I'm talking exclusively about api's obviously), he can't possibly not know about this as well as not know that a certain exchange (in this case, Bter) allows asynchronous requests if he claims that he knows the api of that exchange ("all REST Api Are synchronous , on ANY EXchange"). That's basically the point I was trying to make

Well deisik tells a little more than this 

Of course Rest by definition could be sync or async. all my comments are about Bot Api Integration.
You can perform tasks in many way, but good programming practise makes you decide about what to use.
And when you need to get the result to continue your work sync is the obvious way.
I Can also create a thread and monitorize it while it's running (performing the aPI call), but it doesn't make sense.

I have a lot of thread in my bot, but they NEED to exists.

BUT this is sync, your subscribing class use a sync call.
Is the way you perform the call from Main System -> Subscriber that will have async result.
Your subscriber -> API is sync. It seems async for you because the Main program could continue works.
But if we are talking about that, my system if completedly Async 
My focus was only on HTTP CALL -> API System interface.

Question : if you delegate the response management to a subscribe what your programs will do while is waiting for the response?
Is your bot somewhere on this board? Can i take a look?

the way I do it: Sending a request to the exchange and async subscribing to the response.
You might read about reactive programming... or event driven architecture, or or or or as you are in an java environment, keywords are:
vert.x, akka, RXJava just to name some frameworks...

The only thing "deisik" wanted to clarify, is that RESTful endpoints are not synchronous by definition, as you said in one of your posts. You are using
them in a synchronous way, and thats okay. no problem with that.

So you create order without get the OrderID, or you cancel orders without wait for return code.
What kind of bot did you deploy?