×

Discussion Board

Results 1 to 9 of 9
  1. #1
    Regular Contributor
    Join Date
    Sep 2009
    Posts
    353

    Socket Connection basics?

    I want to implement a socket server on the 5800XM I was wondering if I could connect 5 - 10 clients to it. That means the 5800 would have to run 5 to 10 concurrent threads.

    I read at some place in the Nokia library that the JVM has limit of 128 threads but it didn't speak of any limit of the number of concurrent threads at any point of time.

    Can I do some kind of test on my device that would allow me to test the concurrent thread limit on the 5800XM , alternatively is there any other method of implementing a socket server without having clients to run in their own threads possibly servicing the client one at a time?

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Socket Connection basics?

    Quote Originally Posted by KevinBoyd View Post
    I read at some place in the Nokia library that the JVM has limit of 128 threads but it didn't speak of any limit of the number of concurrent threads at any point of time.
    All threads are concurrent.

    Quote Originally Posted by KevinBoyd View Post
    is there any other method of implementing a socket server without having clients to run in their own threads possibly servicing the client one at a time?
    Two threads. One sits waiting at acceptAndOpen(). When it receives an incoming SocketConnection, it appends it to a queue (say, a Vector), and uses to notify() call to ensure that the second thread is awake. The second thread sits waiting in a wait() call. When it wakes up, it reads SocketConnections from the queue in turn, servicing each one, until the queue is empty, then resumes its wait(). Obviously, make sure that access to the queue are synchronized. Provide a way to limit the queue size, and to refuse incoming connections when the queue is full (advising clients to wait and try again).

    Graham.

  3. #3
    Regular Contributor
    Join Date
    Sep 2009
    Posts
    353

    Re: Socket Connection basics?

    Quote Originally Posted by grahamhughes View Post
    Two threads. One sits waiting at acceptAndOpen(). When it receives an incoming SocketConnection, it appends it to a queue (say, a Vector), and uses to notify() call to ensure that the second thread is awake. The second thread sits waiting in a wait() call. When it wakes up, it reads SocketConnections from the queue in turn, servicing each one, until the queue is empty, then resumes its wait(). Obviously, make sure that access to the queue are synchronized. Provide a way to limit the queue size, and to refuse incoming connections when the queue is full (advising clients to wait and try again).

    Graham.
    Isn't the read() method blocking... so wont the socket servicing thread lock onto the first member of the queue and wait there forever or till data arrives on that socket? how could we service all sockets?
    And I didn't understand the empty part.
    If there are clients A, B and C and Server S. the vector in S will have three socket slots A, B and C. and the service thread will there sequentially service A then B and then C right? assuming all the connections have to be maintained open.
    Or do you mean to say that once a socket has been service it has to be closed?

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Socket Connection basics?

    Well... you need to define "service".

    If "service" involves receiving a request, sending a response, end of story (as is the case with a simple HTTP server), then queuing makes sense.

    If "service" is an on-going process, then you'll need separate threads, or you won't be able to service them simultaneously.

    Graham.

  5. #5
    Regular Contributor
    Join Date
    Sep 2009
    Posts
    353

    Re: Socket Connection basics?

    Quote Originally Posted by grahamhughes View Post
    Well... you need to define "service".

    If "service" involves receiving a request, sending a response, end of story (as is the case with a simple HTTP server), then queuing makes sense.

    If "service" is an on-going process, then you'll need separate threads, or you won't be able to service them simultaneously.

    Graham.
    Ok, If I consider HTTP if two requests arrive at the server, one of client A and one of client B, and the server is busy servicing A's request will B's request be buffered or will it be lost?

  6. #6
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Socket Connection basics?

    You shouldn't lose any data. Just as you don't lose data in the delay between acceptAndOpen() and the first call to read() on the InputStream.

    Obviously, I wouldn't want the delay to be too long, or the client will give up.

    Remember that even if you use multiple threads, only one thread at a time will execute, so only one client will be getting attention at any one time. You can't necessarily service requests faster in parallel than you can sequentially.

    If you only expect 5-10 simultaneous clients, then I wouldn't be concerned about using separate threads to handle them. It might simplify the code.

    Graham.

  7. #7
    Regular Contributor
    Join Date
    Sep 2009
    Posts
    353

    Re: Socket Connection basics?

    Quote Originally Posted by grahamhughes View Post
    You shouldn't lose any data. Just as you don't lose data in the delay between acceptAndOpen() and the first call to read() on the InputStream.

    Obviously, I wouldn't want the delay to be too long, or the client will give up.

    Remember that even if you use multiple threads, only one thread at a time will execute, so only one client will be getting attention at any one time. You can't necessarily service requests faster in parallel than you can sequentially.

    If you only expect 5-10 simultaneous clients, then I wouldn't be concerned about using separate threads to handle them. It might simplify the code.

    Graham.
    Thanks for your explanation, I sometimes forget that threads are actually allotted time-slots for execution, and they actually run concurrently they SEEM to be running concurrently, after all there is only 1 underlying micro-processor that will be executing byte codes sequentially, Right?

  8. #8
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Socket Connection basics?

    It's easy to forget. One on hand, you have to think about threads as running "at the same time", or you forget the need for synchronization. It's easy to start thinking that the threads will happen to execute in the order that suits you! On the other hand, yes, you have to remember that you can't execute any more code in parallel than you have processor cores.

    If all threads are constantly capable of running (they never make any blocking call), then multi-threading will actually slow things down, because time is consumed by swapping threads.

    If threads sometimes block (waiting for data to arrive on a socket, for example), then multi-threading might make things faster, by making use of the processor to do something else while one thread waits.

    Some operations that block one thread might actually block all threads. This is especially true on mobile, where hardware and operating systems are not as sophisticated as desktops or servers. On many devices, writing to RMS is a "stop the world" operation. Garbage collection is also world-stopping. Even J2EE's "concurrent garbage collector" (designed to take advantage of multi-processor environments) has to suspect all threads periodically, just for a shorter period than a conventional GC.

    I usually tell people to avoid multi-threading. In part, this is because phones just don't multi-thread as well as desktop computers. A 100MHz ARM processor will not multi-thread as smoothely as a dual-core, 2GHz Pentium, even without considering the difference in the sophistication of operating systems and Java runtimes. The other reason is: we're not really clever enough. Let's face it, I've worked with some pretty good programmers, and none of them can write bug-free code, even with just one thing happening at a time. I certainly can't. Start making ten things happen at once, and getting your head around the potential interactions is enough to have you reaching for alcohol.

    In general, server applications are one of the best reasons to use threads, because the threads do not interact heavily.

    Graham.

  9. #9
    Regular Contributor
    Join Date
    Sep 2009
    Posts
    353

    Re: Socket Connection basics?

    Many Thanks for the masterclass...
    There is always something new to learn, everytime you reply to a post...
    Cheers!

Similar Threads

  1. Does Nokia 6630 supports Socket Connection?
    By kishorekadiri in forum Mobile Java Networking & Messaging & Security
    Replies: 2
    Last Post: 2006-02-21, 05:20
  2. Unable to do a socket connection
    By PriyankaChaurishia123 in forum Mobile Java Tools & SDKs
    Replies: 2
    Last Post: 2006-02-13, 17:53
  3. Socket problem
    By defragger in forum Symbian
    Replies: 0
    Last Post: 2005-08-25, 08:16
  4. socket connection problem
    By bhatti81 in forum Mobile Java General
    Replies: 2
    Last Post: 2003-10-08, 14:43
  5. PC Sync with 6310i and Socket BT Connection Kit
    By sami_laiho in forum Bluetooth Technology
    Replies: 0
    Last Post: 2002-09-17, 05:25

Posting Permissions

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