ajax - short polling versus websockets for short duration requests -

so have django backend server communicates large number of 3rd party servers. these 3rd party servers use socket connections communication, not http. each user request our service communicate (over socket) 1 of many possible 3rd party servers. each 3rd party server can take 1-20 seconds respond, although around 1-5 seconds. of course when user goes our webpage make request 1 of 3rd party services, want respond our user possible, ie don't block on our server waiting response. when 3rd party server responds, want push response user's browser.

certainly common problem. key here issuing requests our web server every 5 seconds or (e.g. using javascript/ajax in our web pages). understand if able create websocket connection response , leave open, and/or if our requests long duration (say >30 seconds), websockets way go server push. however, variety of reasons can't that, we'll need establish new websocket connection every request. seems me if have go through whole process every 5 seconds of opening websocket, configuring websocket match proper 3rd party service connection, sending command down, proxying command correct 3rd party service, response, proxy proper websocket, , send response browser, , again 5 seconds later, better doing basic short polling? our short polling approach use basic ajax call send request down , return success browser. backend proxy proper 3rd party service, , when results come in, save these results mysql table. our ajax send polling command every second or 2 (possibly backoff, eg 1,1,2,4,6,10,... seconds), until response received or until timeout occurs. implementation way simpler , pretty guaranteed work. in vast majority of cases, issue our "once every 5 second" command, , response after first or second polling attempt. if used websockets, take connection attempt plus 1 or 2 socket write commands configure backend proxy use proper backend service, , we'd response , socket close , we'd have on again 5 seconds later.

so wouldn't short-polling work fine , possibly better in situation?

if you're going set new websocket connection every single request, more overhead use websocket http request.

every websocket connection starts http request/response websocket initialized , want send more packets - that's more , forth http request/response.

the real savings here solve whatever issues making think need create new websocket connection every request. solvable. then, create 1 websocket connection , send messages both ways send requests , return responses , more efficient http polling.

to more efficient http, stop polling entirely client. so, rather client saying "do have new me" every 5 seconds, client establishes websocket connection, instructs server wants notified about, server whatever polling needs done , whenever there thinks client wants, sends client without waiting polling interval. client gets data faster (it doesn't have wait next polling interval), there no empty polling requests/responses server usage , bandwidth usage both better.