Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 26
  1. #11
    Thanks for the clarification, that makes sense now.


    I've added those extra log settings and attached the updated server log.


    And also I have a Wireshark .pcapng which shows what the messages look like from the client side. I'm not sure that my title for this thread is correct, the bind_session.txt requests look like they did receive responses? If so then that in turn would mean that my Postman setup is not representative for some reason.


    I'll admit I'm still trying to make heads-or-tails of the Wireshark output.


    Please could you priovide us with the details about the client library in use in these tests (library type and version)?

    I am using


    Code:
    pod 'Lightstreamer_OS_X_Client'

    which is at version 2.0.0. I'm testing in an OSX project so as to keep things simple, but I had the same results when I was using Lightstreamer_iOS_Client, and the non-unified API as well.
    Attached Files Attached Files
    Last edited by abcdefg; September 6th, 2016 at 05:51 PM.

  2. #12
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    First, please note the OS X Client API (Unified Version) version 2.0.x is compatible with Lightstreamer Server since version 6.0.1.
    Most likely this is not the reason of the issue, since also happens with other libraries, but generally using a client lib not supported by the Lightstreamer server version in use exposes you to unpredictable behavior.

    That said, the new log and the client side dump offer us some clues to explain the situation.
    In fact we often find errors of this type, in the IP protocol:

    "Header checksum: 0x0000 [incorrect, should be 0x6ec5 (maybe caused by "IP checksum offload"?)]"

    These happen in the ack messages from the client to the server.
    Now I can imagine at this point a scenario like this: the server does not receive the ack for his reply to create_session, for this reason the session remains stuck, and the following bind_session request does not receive any reply.

    Regards,
    Giuseppe

  3. #13
    It is interesting however apparently a 0x0000 checksum might just be a quirk of Wireshark when capturing the packets.

    https://ask.wireshark.org/questions/...rect-should-be

  4. #14
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Could you take a sniff server side?

  5. #15
    No problem, I've attached.

    In the server logs, it looks like the header checksums are ok in both directions, so I'm guessing that this is just a recording quirk.
    Attached Files Attached Files

  6. #16
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdef,

    You are right, these new captures show a correct situation from the network point of view.

    However remains a strong suspicion that the sessions remain in some way stuck.

    The best way to proceed the investigation is to reproduce the case with a server 6, and if the issue persists, I will provide you with specific instructions.

    Regards,
    Giuseppe

  7. #17
    I think I might have isolated the problem.


    Our servers run Lightstreamer 5.1.1. In 5.1.2 you added the <use_enriched_content_type> property which changes the Content-Type of messages from text/plain to text/enriched. Our servers don't have this flag set and Wireshark confirms that the Content-Type is text/plain not text/enriched.


    From my testing, when the server sends text/plain messages, the Flash client will respond and connect, but the iOS client won't.


    I have tested this with our 5.1.1 production server, with a 5.1.2 server, and with 6.0.3 server with <use_enriched_content_type>N</use_enriched_content_type> and it seems to be completely consistent and reproducible.

  8. #18
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    This is quite strange since the recent results do not agree with my previous considerations. In the log files I have checked so far the client lib always replied (with a bind request) to the server create_server reply.

    Indeed as stated in the in-line comments of the <use_enriched_content_type> parameter, it is generally useful to work around possible buffering by network intermediaries (which is not your case).

    That said, if the <use_enriched_content_type>Y</use_enriched_content_type> setting helps in your case you should consider the option of a Lightstreamer server upgrade.

    Regards,
    Giuseppe

  9. #19
    Could you just confirm for me that you can NOT reproduce this behaviour

    Server: Lightstreamer 6.0.3
    Server setting: <use_enriched_content_type>N</use_enriched_content_type>

    Client: Lightstreamer_OS_X_Client
    Client code:

    Code:
        override func viewDidLoad() {
            super.viewDidLoad()
            
            LSLightstreamerClient.setLoggerProvider(LSConsoleLoggerProvider())
    
            let client = LSLightstreamerClient(serverAddress: "https://....:443/", adapterSet: ".....")
            client.addDelegate(self)
            client.connect()
        }
        
        func client(client: LSLightstreamerClient, didChangeStatus status: String) {
            NSLog(status);
        }
    Output:

    Code:
        CONNECTING
        CONNECTED:STREAM-SENSING
        CONNECTED:HTTP-STREAMING
        CONNECTED:HTTP-POLLING
        DISCONNECTED:WILL-RETRY
        CONNECTING
        CONNECTED:HTTP-POLLING
        DISCONNECTED:WILL-RETRY
        CONNECTING
        CONNECTED:HTTP-POLLING
        DISCONNECTED:WILL-RETRY
        CONNECTING
        CONNECTED:HTTP-POLLING
        DISCONNECTED:WILL-RETRY
        CONNECTING
        ...

  10. #20
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    I can confirm that I can NOT reproduce the behaviour. My test conditions:
    - Lightstreamer server 6.0.3 listening on localhost:8080 (no SSL)
    - client OS X version 2.0.1
    - <use_enriched_content_type>N</use_enriched_content_type>

    But the results of your tests continue to confuse me; especially the server-side network sniff analyzed.

    It may be that between the sniff and the Lightstreamer server there is some software component such as antivirus, firewall or similar?

    Regards,
    Giuseppe

 

 

Similar Threads

  1. SYNC Error on bind_session
    By shifter1 in forum Client Protocol
    Replies: 1
    Last Post: November 18th, 2013, 10:14 AM
  2. Upgraded to LS 4 and many POST bind_session.txt
    By Adrian Parker in forum Client APIs
    Replies: 2
    Last Post: November 21st, 2011, 04:03 PM
  3. Pull data from txt file to lighstreamer (NEWBIE)
    By forexinvestor in forum Adapter Protocol
    Replies: 1
    Last Post: December 23rd, 2008, 09:55 AM
  4. Trying to run LS through Https / SSL
    By wmolde in forum Client APIs
    Replies: 2
    Last Post: April 18th, 2007, 04:40 PM
  5. GETTING_STARTED.TXT doubts
    By rmusco in forum General
    Replies: 11
    Last Post: November 30th, 2006, 11:25 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 11:42 PM.