Do you use a bot for trading?

[Bitcoinsummoner]

carap: what language do you use for bot coding?

We primarily use Delphi, MatLab, PHP (since we have a great experience with these technologies).

However, IMO language itself is not important, the same could be created on Java, C or Python. 

Do you done in this project or this bot.. can you share it with us or pm me the bot to download also the resources or github.
For basic understanding i want to find a bot the works and more features.. setup.
Everything in trading is in your strategy but we can easily earn more if we use bot..

[audaciousbeing]

Even the manual trading I am yet to master it not to talk of taking it professional by now using a bot. I don't even understand how the not will even work and another discouraging factor is the issue that it does not guarantee that profit will be made or losses will not be made so I just stick to taking a decision I can completely take responsibility for its outcome.

[Sampey]

Well i really start thinking that it's not possible to talk with you :

HTTP LIBRARY is a CLIENT environment library to perform HTTP CALL. OK? A Library on CLIENT SIDE that will makes you perform HTTP CALLS using REST API

I use java, so for example :
this is a HTTP Library : http://hc.apache.org/httpclient-3.x/
this is another java http library https://docs.oracle.com/javase/7/docs/api/java/net/package-summary.html

Ok?
This is a code example :

And here you can find some java code example if you wants to learn something useful

https://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/

As I already told you, if you send two authenticated requests to this exchange, your last request (by timestamp) can be be processed first. This doesn't work with other exchange but it works with Bter. Instead of arguing, you'd better really try it out

This has nothing to do with async or sync call.
I Can create 10 sync call that starts at the same exact moment.

There's only 1 problem : you must set a NONCE.
Do you know what is a NONCE, i'm sure yes, you're an expert 

NONCE is created to discard eventually http call with a nonce lower than the last use.

So in your example if i send First CALL 1 And Then CALL 2 BUT for any reason CALL 2 arrives to API System before CALL 1, then CALL 1 will be discarded.
If bter doesn't do that (Standing at what you said) there are 2 reason :
1 - It's bad written
2 - You're not using the BTER REST Api system
May exchanges offers different API System

OkCoin for example offers 3 API System
https://www.okcoin.com/about/rest_api.do

Well the next will be my last post.
Choose the last things to say, i will make only 1 last reply, i'm not here to loose time, and i'm not here to make me troll without any specific reason.

[wilson76]

the way you manage the API Call inside your Client it's up to you, but the HTTP CALL from your Client to API System in a REST environment is Sync.

A RESTful endpoint can be either synchronous or asynchronous.
As the C.A.T. bot is implemented in Java, you might have a look into JAX-RS 2 specification.

The limitation to send more than one request at a time, is at most exchanges the "nonce".

Edit:
@Sampey: Here is one explaining async REST Services implemented in Java:
https://dzone.com/articles/jax-rs-20-asynchronous-server-and-client

But the whole discussion is a little bit cherry-picking into details....

[Sampey]

the way you manage the API Call inside your Client it's up to you, but the HTTP CALL from your Client to API System in a REST environment is Sync.

A RESTful endpoint can be either synchronous or asynchronous.
As the C.A.T. bot is implemented in Java, you might have a look into JAX-RS 2 specification.

Yes of course, never Said that you can't perform an async call. BUT when you need the result to continue your computation you must perform a Sync call.
For example, my bot is 100% sync, but i'm pretty sure 99% of Bots are sync

About JAX-RS 2 i just use JAVA.NET i don't need nothing more to make POST/GET REST CALL. 

[deisik]

Well i really start thinking that it's not possible to talk with you

~snipped~

Mate, let's forget about Bter (after it got hacked it is no longer relevant, anyway)

I'm not really interested in continuing this discussion about Bter (it was only a sort of reality check). As I said, this is not a pissing contest, so I basically don't give a fuck since what I wanted to find out I found out. What I'm really interested in at the moment is your claim that the REST services should necessarily be synchronous. In fact, I don't really see how the idea of either synchronous or asynchronous requests, or, in a more broad sense, such api's has anything to do with that, but I think it won't take much of your precious time to expand more on this. For example, you could reveal some RFC (or other binding standard) defining exactly that, namely, how REST compliant api's are required to be synchronous, since this is what you are essentially claiming

[Sampey]

@Sampey: Here is one explaining async REST Services implemented in Java:
https://dzone.com/articles/jax-rs-20-asynchronous-server-and-client

YEah i know about that, and i've also develop async call, but not in Bot environment.
I create async call with dedicated thread to wait result and send it back to the main sistem, or async call where next computation part is demanded to another thread on another system and client doesn't know nothing about result.

BUT, i'm pretty sure you can agree with me that if you write a Trading BOT, you will use REST API Sync CALL.  

[wilson76]

BUT, i'm pretty sure you can agree with me that if you write a Trading BOT, you will use REST API Sync CALL.  

No, definitely not... I hate blocking threads and waiting 2 seconds for a response from the exchange ...
sure, I need the result of my request at some point, but not in a sync 

[Sampey]

the REST services should necessarily be synchronous

Never say that. I'm talking about a BOT Context. Not about the world of the REST api Call.
If you read my previous reply i develop by myself in async context.
BUT if we talk about BOT, async response is not useful, i need to get data, i can't continue my work without getting the resul :

Just an example

- If i want to delete an order i must wait for the OK response, because if response is KO i need to find for the trade that fills the order
- I want to have best market prices, i need to call MarketOrders and then get the 2 TOP elements
- I want to create an orders, i need to wait for return code OK and read market ID

Any Calls my bot use need the response.

BUT if you wants to use the MARKET EXPLORER function (that ONLY loads order/trades/myOrder/Mytrader) after you press the LOAD Button, then a dedicated thread will start to popolate the table while you can change screen and continue your work.
This is async BUT, not at API level, because i will perform 4 Sync Call to collect data and then i will show results in 4 tables. So workflow is

UPDATE BUTTON PRESS -> ASYNC THREAD -> 4 SYNC API CALL -> POPULATE  TABLES with REsponses.

[Sampey]

BUT, i'm pretty sure you can agree with me that if you write a Trading BOT, you will use REST API Sync CALL.  

No, definitely not... I hate blocking threads and waiting 2 seconds for a response from the exchange ...
sure, I need the result of my request at some point, but not in a sync 

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

[wilson76]

BUT, i'm pretty sure you can agree with me that if you write a Trading BOT, you will use REST API Sync CALL.  

No, definitely not... I hate blocking threads and waiting 2 seconds for a response from the exchange ...
sure, I need the result of my request at some point, but not in a sync  

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

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.

[Sampey]

the way I do it: Sending a request to the exchange and async subscribing to the response.

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?

[Sampey]

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.

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.

[deisik]

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

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

[wilson76]

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

[wilson76]

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. That's basically the point I was trying to make

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.

[deisik]

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. That's basically the point I was trying to make

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

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

[Sampey]

The same point I didn't get: How did he 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.

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?  

[Sampey]

For example, you can send a new order request and at the same time, without waiting for a reply to this request

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 

[wilson76]

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. That's basically the point I was trying to make

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

This is called asynchronous mode of operation

There is no problem with that since no one forces to use this mode. If you need to wait for a reply, you just wait and that's 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 if I remember correctly (I don't use this exchange for over a year already), send a few other requests cancelling a bunch of other orders. For example, with Bifinex api you can easily cancel a few orders with just request, 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 requests simultaneously

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