Place another bet without waiting 1 second ?

[StefanBelo.]

Clearly you disagree with my comments - that is your perogative. However, please keep your interactions civil and, if you have anything to add to the conversation, then please post it so we can all learn.

If you just want to snipe, then save your breath. Nobody wants to hear it.

Man, you edited all your comments here. You said something then changed your opinion.

I just asked whether you are a software developer, I asked because you offer api product as well, and was wondering who made that app having clearly problems with base programming tasks.

[betdynamics]

You are correct. I clarified some statements and edited some spelling. No change in opinion.

Sorry to disappoint you further!

[jptrader]

StefanBelo, please keep attacks on other API developers off this forum. Unlike some other API developers, betdynamics does not use this forum to promote his application, but is just very helpful.

[jabe]

Ah, i understand now Jabe, i didn't notice it was an edit, sorry.

Not a problem at all. I must admit that I hadn't noticed that the original and third posts were from different people, and I wasn't happy with the tone of the third one. I forget too that not everyone is a native English speaker. "Rescind" is not the most common English word.

I too, once past the initialization, that is sequential, use threads. I thought about spinning every API request in a thread pool but i then gave up because performance was good enough and i didn't want to embrace the concurrency issues that might occur. Im still using a thread pool for some operations.
I'm also using VB.Net, i haven't experiment with the Async/Await, i have read about it but haven't fully realized differences between tasks, threads, for parallel, and so on. Will give it a try. If some one cares to show an example of a placebet with the async await in .net it would be great.

I was a professional programmer, but that was centuries ago, and in Cobol. There is such a lot in VB.NET that is new to me, or seems to behave in a way that makes little sense. I should, perhaps, check what AWAIT does, but I read the famous Mumbles thread on the previous API and I think that uses AWAIT. When the new API came out, AWAIT appeared to be something old. Maybe not!

[LiamP]

I use python, used to start a new thread for each order request but have now moved to an event driven concurrent queue utilising grequests (great library, uses requests)

Interested to find out what other python users do?

[pythonic]

I'm using python2 with threads and requests for historical reasons, because I never felt motivated to port my code to python3.

Threads are a historically very common generic solution to the problem of asyncronous IO and they work fine when used carefully.
In recent web oriented programming languages there are often specific language constructs like the async / await syntax which are designed specifically to deal with asyncronous IO in REST APIs because this is a very common task nowadays.

So if you have such a language construct in your programming language then the obvious way to go would be to use that.
If you don't, then you can always use threads.

grequests also looks nice. If you look at the code, it is basically a very thin wrapper around requests with coroutines.

I would also like to point out that PEP 0492, which introduced async / await to python3.5, is only one year old.
So the implication that anyone who doesn't use this particular syntactic construct is not a real programmer is a bit silly.

[aye robot]

I use Python and I call every request in a new thread.

I don't claim any great programming expertise - pretty much all the programming I know I learned in order to write betfair bots so maybe I'm not doing it in the optimal way but it certainly works - I've been doing it that way for years.

[Guest]

Background Threads

Place your bet on a background thread (or just a thread) and use another thread if you want to place another bet.

Hi BetDynamics, I have developed my App in VB.NET. Originally to speed up my program I was using background threads to request and receive my BF calls, however after a while the program would have issues passing information between the threads (VB net calls these background workers). After a while I removed the threads and went back to timer interrupts and just waited.

Now I am thinking of using threads again. Do you have any advice on how to pass data. One thought it to use a central database, or file system so my main program thread can save the betfair instructions and the background thread simply reads processes and then post the results.

[LiamP]

Do VB Net threads not allow you to share memory?

[jabe]

Here's a little about how my VB.Net program works.

It may not be the most efficient way of doing things.

There is a global collection of sporting events. They are football matches and the definition is as follows, keyed on matchId (which is the EventId):

Public Shared WithEvents fixture As New ConcurrentDictionary(Of String, ClassFootballMatch)

ConcurrentDictionary items are thread safe - which means there will be no conflict from multiple updates of a particular item.

A list of fixtures and a timer is used to update each fixture with the latest odds on a regular basis. If the circumstances after receiving the latest odds require a bet to be placed, an event is raised by the fixture. Raising the event sends data from the fixture to whatever routine is assigned to deal with it (the examples below don't necessarily show bet placing code).

The event is defined in the fixture class, like this

Event PleasePrintMessage(sender As Object, e As ClassMessage)

and is triggered like this (still within the same class)

 RaiseEvent PleasePrintMessage(sender As Object, e As ClassMessage)

The data being passed is in e - the ClassMessage - in this instance. Importantly, when you create a class for passing data when an event is raised it MUST inherit EventArgs, thus

Inherits EventArgs

In the main part of the program, each fixture already had an event handler added, like this

AddHandler fixture(matchId).PleasePrintMessage, AddressOf PrintMessage

There may be a better way to add the event handler, but adding it (or them) when the fixture was added to the collection works fine.

The handler points to a subroutine called PrintMessage. In this particular case, all it does is add the message to a queue which is dealt with once a second using a timer. For events that require bets to be placed, the subroutine mentioned in the AddHandler will create a new thread that will send an API request and pass the returned string to the fixture.

I'm about to add the code to deal with events raised to do such things, so I can't post any of it yet. However, what will happen is that the subroutine indicated by the AddHandler will be defined like this

 Public Sub PrintMessage(sender As Object, e As ClassMessage)

and will receive the data sent when the event was raised in the ClassMessage object (or whatever it is).

In the bet specific subroutines, a new thread will be created, like this example

      Dim t1xThread As New Thread(AddressOf GetMatchMarketBook)
      t1xThread.Priority = Threading.ThreadPriority.Normal
      t1xThread.Start(matchId)

I have included matchId as part of all the classes used when events are raised, so the code always knows which item in the collection raised the event.

The GetMatchMarketBook routine is run asynchronously. Stripped down, it looks like this

GetMatchMarketBook(matchId)
        Dim markets As String = fixture(matchId).GetMarketString()
        Dim instring = API_listMarketBook(markets)
        fixture(matchId).MarketBookInput(instring)
End Sub

As you can see, for this call it needs to get data from the fixture; it then makes the API call and then passes the returned data to the fixture, which has a routine called MarketBookInput to deal with it.

I hope that's useful. As I said, I'm about to add the code to deal specifically with the actual betting, so if anything else important arises, I'll add it here.

[Guest]

Thanks

WOW Thanks Jabe, this has been helpful. I went back to some of my older versions where my background workers where simply scraping other websites to compare data. I noted that I was using these background threads to interact with my main form and update progress bars (ie how far through the website) and this is where I had the issues.

I also have a global data Structure which I use so I could return to threads to update my data. I think I am going to re-visit this so thankyou all and Jabe.

PS. These days I don't scrape other websites as they all have some sort of API which you find and there any many websites out there which can help you create a class from the JSON data.


Oh ..... Re-reading back on this thread, I thought I would also ad that I am a programmer from a while back (use to program JOVIAL (very C like) for the F/RF-111C aircraft). Back then in my down time I wrote apps in VB6 and fell in love with the ease of the language, however when I decided to code my bet bot I jumped to VB.NET. Although I like to believe I am a good programmer the language is so large and powerful that I continue to learn new things about the language all the time.

[jabe]

I've just re-read my thread and there are a couple of minor things:

1. When creating a new thread, this line

t1xThread.Priority = Threading.ThreadPriority.Normal

may not be necessary. Not sure. It might have come from wherever I borrowed the code from.

2. As you'll have expected, the decision to bet or not is taken within the fixture class, since that's where all the relevant data is.


It sounds like we're in the same boat - not only learning how to have a program talk to the Betfair API, but also learning a new or newish language and having to deal with some of its odd corners.

Good luck with your tweaks!