sta / sta/websocket-sharp

HttpServer strange behaviour with safari mobile

Open
#232 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
6.1k
Forks
1.7k
PR merge metrics
No merged PRs in 30d

Description

Good evening,
i'm using websocket-sharp as both http and websocket server. Despite the fact i can connect to my application from any browser my main interest is to deploy app for both apple and android.
I anticipate that chrome on android doesn't present any problem while safari on mobile (iOS 9.2.1 13D20) is giving me an hard time.
What's more i seem to not replicate any issue on my debug environment in local network but i have some difficulties on deployment servers with internet connection.

In particular I've stumbled upon two major problems:

  1. If i quickly refresh a web page on safari mobile using an internet (adsl) connection to my websocket-sharp remote server it (the server) will become unresponsive and I won't be able to make any more requests even from other devices;
  2. If I try to request the page of my application from safari mobile on a rather slow internet connection or from multiple devices simultaniously the page won't load correctly all its dependencies resulting in a white screen.

More details

  • The web page i'm trying to load uses sencha framework 2.0.1.1 and it makes alot of link requests to the server in order to use a complex server structure of classes (it requests around 90 files).
  • I've tried to play around with the websocket-sharp project i downloaded from the repo Friday and adding a sleep of 100 ms onto the receiveRequest method of the class HttpServer.cs always reproduces the issue for mobile safari like so:
private void receiveRequest()
{
    while (true)
    {
        try
        {
            var ctx = _listener.GetContext();
            System.Threading.Thread.Sleep(100);

            ThreadPool.QueueUserWorkItem(...

Possible workarounds

  1. In order to avoid the server block I've modified the onAccept method of EndPointListener.cs to rebind the onAccept in case the socket is null like so:
private static void onAccept(IAsyncResult asyncResult)
{
    var lsnr = (EndPointListener)asyncResult.AsyncState;

    Socket sock = null;
    try
    {
        sock = lsnr._socket.EndAccept(asyncResult);
        lsnr._socket.BeginAccept(onAccept, lsnr);
    }
    catch
    {
        if (sock != null)
            sock.Close();
        else
            lsnr._socket.BeginAccept(onAccept, lsnr);

        return;
    }

    processAccepted(sock, lsnr);
}
  1. The only fix i found to avoid the misbehaviour for mobile safari is to put the timeout for the HttpConnection.cs on successive requests to a very small amount (around 100ms) and make it close the connection after every request.

I would like to know if it's possible to fix these problems in a more elegant way and to include the modifications in one of the next releases for nuget.
Thank you in advance for your time, I'll be waiting for an heads up.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the reported behavior with mobile Safari, slow or simultaneous requests, and the 100 ms delay in HttpServer.cs. Inspect receiveRequest in HttpServer.cs, onAccept in EndPointListener.cs, and the timeout behavior in HttpConnection.cs; done means the server remains responsive and all page dependencies load without relying on the reported workarounds.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.