Thread: Tracking external user IDs in threaded tcp server.

  1. #1
    Registered User
    Join Date
    Mar 2008
    Posts
    17

    Tracking external user IDs in threaded tcp server.

    Hi,

    My scenario is similar to shopkeepers and customers. Shopkeepers open a long running tcp connection to the server, and have interactions with customers who have short lived tcp connections. I need to be able to relay messages between a shopkeeper and its current customer. A shopkeeper will serve multiple customers over time, but only a single customer at any given moment.

    Both shopkeeper and customer have an external (database) id, and the protocol states that the customer asks: "buy 10 from ed1a5", where "ed1s5" is the shopkeeper id. And then the shopkeeper responds, "ok to bac43", with "bac43" being the customer id.

    What's the best (simplest) data structure pattern to handle this, and to easily refer to both shopkeeper and customer from their respective threads? Given when the client connects I have to find the shopkeeper thread (to send the data msg) based on the shopkeeper id "ed1a5".

    To simplify things I think I only need to 'lookup' the shopkeeper from the customer, which then takes a reference to it and sets itself (the customer thread) on the data structure that the shopkeeper uses in respond_to_customer(on_thread, msg). So the shopkeeper would never need to lookup the customer thread based on the customer id.

    I guess a generic find_thread_for_id(str) is probably best overall, which implies a hash table keyed off shopkeeper id and containing the a pointer to the thread_id?

    thanks,
    Last edited by dougieb; 09-04-2018 at 04:23 AM. Reason: a bit more info

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    Sounds good to me.

    Start with something fairly simple that you know will work. You can profile and optimise later on if necessary.

    Overly fancy solutions which take a long time to develop / debug / test / verify / maintain for no good reason isn't the way to go.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Mar 2008
    Posts
    17
    For anyone else thinking of similar things, the K&R C book (Ansi C edition) has a pretty good example (page 145 in my copy) to get started.

    This hashing function seems to produce a very equal distribution (for my data), even at very low numbers of hash table buckets.

    Code:
    unsigned hash(char *s) {
        unsigned hashval;
    
        for (hashval = 0; *s != '\0'; s++)
            hashval = *s + 31 * hashval;
        return hashval % HASHSIZE;
    }
    Based on inserting 100,000 char[32] guids into a 10 bucket hash table:
    Code:
    [0] 9787 items
    [1] 10067 items
    [2] 10064 items
    [3] 10061 items
    [4] 10108 items
    [5] 9962 items
    [6] 10044 items
    [7] 9999 items
    [8] 9988 items
    [9] 9920 items
    takes about 8 seconds on my iMac/Vagrant. But increasing the bucket count to 1000 and running the same test takes only 0.1 seconds, so easy to bring down the time to insert then walk through the records.

    cheers,

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. need help with Tracking user login
    By erictu in forum C++ Programming
    Replies: 25
    Last Post: 04-01-2012, 06:57 PM
  2. Issue with multi-threaded tcp server
    By mcmillhj in forum C Programming
    Replies: 4
    Last Post: 03-19-2011, 02:09 PM
  3. Multi-Threaded Server Help
    By jonswits20 in forum C# Programming
    Replies: 5
    Last Post: 04-17-2007, 11:05 PM
  4. multi-threaded web server problem!!
    By jayhor in forum Windows Programming
    Replies: 2
    Last Post: 08-11-2006, 11:22 AM
  5. Multi-threaded UDP Server Problem
    By nkhambal in forum C Programming
    Replies: 0
    Last Post: 07-05-2005, 02:27 PM

Tags for this Thread