×

Discussion Board

Results 1 to 7 of 7
  1. #1
    Registered User
    Join Date
    Jun 2003
    Posts
    2

    Persistent connection

    My current project relies on long-lasting connections to the server. How is this best implemented with MIDP v1.0? I've implemented it with a pair of HttpConnections (one GET, one POST), which remain open for the midlet's lifetime, but that doesn't work on the phones I've tried (CSD only so far, it might still on GPRS). So I'm trying a rather nasty polling system which wastes bandwidth something chronic - is there an elegant way of doing this?

    Of course, all gravy once v2 is widely supported and I can use UDP datagrams, but until then, what is everyone else doing?

  2. #2
    Registered User
    Join Date
    Jun 2003
    Posts
    2
    I am trying a similar thing, trying to open two POST connections, one for sending and one for receiving. It works in the WTK104 emulator, but fails in various ways on various phones. Is there a recommended way of faking HTTP out? BTW, my app works fine on the phone that supports sockets.

    Kelton

  3. #3
    Registered User
    Join Date
    Jun 2003
    Posts
    2
    keltonflinn: I'm not surprised. What's happening is that we're falling foul of the WAP mechanism. It's not actually HTTP, it's an encoded version of it. As a result, the entire request is cached on the gateway server, and only sent when it's finished transferring from the phone to the gateway. A phone which supports sockets will by definition support normal TCP/IP, and so will be able to start sending HTTP data before the request is finished.

    Basically, sucks to be us
    Sun just wasn't thinking of real-time applications when it designed MIDPv1, and it'll be a while before MIDPv2 happens. Right now, how I'm doing it is to have two versions - one with the bandwidth-minimising method which works in the emulator (and presumably socket phones, don't have one to test), and one for less intelligent phones which just polls repeatedly. If you are interested in a polling solution, might I also incidentally recommend kxmlrpc. Doesn't work when streaming, but makes life SO much easier...

  4. #4
    Registered User
    Join Date
    Jun 2003
    Posts
    2
    Thanks! That helps, I think

    One of the books I have suggested putting "really big numbers" in the Content-Length. That seems to work in the emulator, but it strikes me as a very fragile solution.

    The other wierd behavior I am seeming is that one of the phones opens a new http connection every time I do a flush() on the DataOutputStream, which needless to say the emulator does not do.

    I think I was not quite clear in my previous post. The "sockets" version of the midlet and the server work fine. The http version of the midlet has the above-described erroneous behavior on that socket-supporting phone.
    Kelton

  5. #5
    Registered User
    Join Date
    Mar 2003
    Posts
    33
    We've just completed an Instant Messaging client which has many of the same requirements you mention.

    Here are some learnings ...

    1) Ignore the emulators. Their networking behaviour has nothing in common with an actual device
    1a) Coz devices tend to support only a single extant connection
    1b) Coz devices often (eg Series 40) map http to cWAP
    1c) Which allows the network operator to munge, cache, block, timeout and drop data at their cWAP gateaway
    1d) Coz Nokia devices are totally bug-infested when it comes to networking
    1e) Coz networking parameters such as timeouts vary greatly and whatever you set it to, the cWAP gateway will timeout anyway
    1f) Coz standard tricks such as closing an http connection to force a timeout don't work on most devices

    2) MIDP 2.0 does *not* mandate Sockets or UDP. It's a reasonable expectation that most manufacturers will take the opportunity of MIDP2.0 to implement same, but it is not guaranteed

    3) The use of sockets implies that your network has an Internet APN open for socket use. Dangerous assumption, especially with prepay !

    The good news is that it can be done. It's just a lot like spinnig plates.

    btw. In Sun's defence, they didn't screw up MIDP 1.0 all by themselves. They had some fantastic help from the handset manufacturers. MIDP1.0 doesn't say a manufacturer *can't* implement sockets. (and as I mentioned above, MIDP2.0 doesn't say they must). imho it's the JCP process that's broken, but that's another story.

  6. #6
    Registered User
    Join Date
    Apr 2003
    Posts
    47
    thx rsmithh for the great tips!!!!

    can you tell me something more about your Instant Messager?
    here or by mail?

    plz send an email to me : gicio@web.de




    gicio

  7. #7
    Registered User
    Join Date
    Apr 2003
    Posts
    47
    or is your application a secret???


    gicio

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •