Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. Async vs Sync

Async vs Sync

Scheduled Pinned Locked Moved C#
helpvisual-studiosysadmintutorialquestion
6 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    Jacob D Dixon
    wrote on last edited by
    #1

    Well I am working on my first Clients / Server application. First I started off working with syncronous sockets, and then switched to asyncronous sockets. The way it looks like it is going to work for now (until I get a better understanding) is the Client connects to server, Client sends data to server, Server gets data, Server looks for data pertaining to that specific client, Server returns data to client, connections close and end. I see a problem though? What if the client connects to the server, sends data to server, server gets it, then server loses connection to the internet? This would mean that my client is stuck on the BeginReceive part. I can't find a timeout. Now I haven't tried to test this yet.. but I was wondering how to handle this situation? Would syncronous sockets be better than asyncronous?

    L 1 Reply Last reply
    0
    • J Jacob D Dixon

      Well I am working on my first Clients / Server application. First I started off working with syncronous sockets, and then switched to asyncronous sockets. The way it looks like it is going to work for now (until I get a better understanding) is the Client connects to server, Client sends data to server, Server gets data, Server looks for data pertaining to that specific client, Server returns data to client, connections close and end. I see a problem though? What if the client connects to the server, sends data to server, server gets it, then server loses connection to the internet? This would mean that my client is stuck on the BeginReceive part. I can't find a timeout. Now I haven't tried to test this yet.. but I was wondering how to handle this situation? Would syncronous sockets be better than asyncronous?

      L Offline
      L Offline
      Luc Pattyn
      wrote on last edited by
      #2

      Hi Jacob, this is how I see it: 1. there are no synchronous or asynchronous sockets, all sockets are the same; however you can operate them in sync or async way; you can choose your way separately for clients and servers. 2. you can always mimic an async operation by launching a separate thread that works synchronously. The disadvantage is cost (one more thread, with its state and stack), the advantage is comfort, as you have less of a problem remembering your state. 3. The .NET Socket class supports ReceiveTimeout in sync mode only; when using the async methods, if you want some kind of timeout, you have to implement it yourself. And even then, it will not pre-empt an outstanding async Receive, all it will do is tell your app sooner the data isn't coming (in time). 4. Assuming your client is using only one or a few sockets at any point in time, I don't see much objections to using the thread and sync mode there. On the server side, the potential number of clients may force you to work in async mode. Hope this helps.

      Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

      Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

      J 1 Reply Last reply
      0
      • L Luc Pattyn

        Hi Jacob, this is how I see it: 1. there are no synchronous or asynchronous sockets, all sockets are the same; however you can operate them in sync or async way; you can choose your way separately for clients and servers. 2. you can always mimic an async operation by launching a separate thread that works synchronously. The disadvantage is cost (one more thread, with its state and stack), the advantage is comfort, as you have less of a problem remembering your state. 3. The .NET Socket class supports ReceiveTimeout in sync mode only; when using the async methods, if you want some kind of timeout, you have to implement it yourself. And even then, it will not pre-empt an outstanding async Receive, all it will do is tell your app sooner the data isn't coming (in time). 4. Assuming your client is using only one or a few sockets at any point in time, I don't see much objections to using the thread and sync mode there. On the server side, the potential number of clients may force you to work in async mode. Hope this helps.

        Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

        Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

        J Offline
        J Offline
        Jacob D Dixon
        wrote on last edited by
        #3

        Ok thanks! My server could possibly be accepting 50-100 connections. If you have agents out there checking in every 2-5 minutes. So I should implement the asyncronous method on the server end, and use syncronous on the client? That way I can specify a timeout and won't get in a situation like I mentioned above. Do you see any real objections to doing something like that?

        L 1 Reply Last reply
        0
        • J Jacob D Dixon

          Ok thanks! My server could possibly be accepting 50-100 connections. If you have agents out there checking in every 2-5 minutes. So I should implement the asyncronous method on the server end, and use syncronous on the client? That way I can specify a timeout and won't get in a situation like I mentioned above. Do you see any real objections to doing something like that?

          L Offline
          L Offline
          Luc Pattyn
          wrote on last edited by
          #4

          Yes, that is what I would do in a first iteration, as it keeps the clients simple, and optimizes the server. :)

          Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

          Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

          J 1 Reply Last reply
          0
          • L Luc Pattyn

            Yes, that is what I would do in a first iteration, as it keeps the clients simple, and optimizes the server. :)

            Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

            Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

            J Offline
            J Offline
            Jacob D Dixon
            wrote on last edited by
            #5

            Awesome! Thanks for the replies. I will use async on server side and sync on client side.

            L 1 Reply Last reply
            0
            • J Jacob D Dixon

              Awesome! Thanks for the replies. I will use async on server side and sync on client side.

              L Offline
              L Offline
              Luc Pattyn
              wrote on last edited by
              #6

              You're welcome. :)

              Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

              Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups