[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

socket

Posted on 2011-02-24
14
Medium Priority
?
509 Views
Last Modified: 2012-05-11
I have a client server application:

Client) Continues listen and waits on recv()
Server) has 2 threads
      Thread 1) Continously sends data
      Thread 2) Send data every 30 secs.

I have noticed many times,
1) Thread 2 in Server simply waits for ever during send()...
2) As soon as thread 1 sends some data, thread 2 just finishes.

What could be going wrong?


Can the server simply send() even though client is not waiting on recv()
0
Comment
Question by:learningunix
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 3
  • 2
  • +2
14 Comments
 
LVL 9

Expert Comment

by:AriMc
ID: 34975815
Sending the source codes of your applications could help.

0
 

Author Comment

by:learningunix
ID: 34975832
This what I have noticed:

Thread 1 and Thread 2 both calls socket send() using

mutex_lock()
  send();
mutex_unlock()

It looks like Thread 2 is holding the lock and waiting on send() forever (looks like client is not receiving at this time. What is the max data that can be send over the line?)
Because of this Thread 1 can't hold the lock.

0
 

Author Comment

by:learningunix
ID: 34975925
actually the other way, thread 1 continously sends data and after some time it just simply waits on send()
(probably client is not receiving). thread 1 is holding lock.

as a result thread 2 is not able to acquire lock.

The only reason I need thread 2 is to send a mesaage to client that i am still alive but thread 1 is already stuck in send()
0
Will your db performance match your db growth?

In Percona’s white paper “Performance at Scale: Keeping Your Database on Its Toes,” we take a high-level approach to what you need to think about when planning for database scalability.

 

Author Comment

by:learningunix
ID: 34975947
the whole point of thread 2 is to make sure the connection is kept alive by sending message every 30 secs. in case thread 1 is taking some time.

However if the thread 1 itself can''t send anymore data (probably either client is not receiving or poll() is not allowing me to write ) how can thread 1 send any data.
0
 

Author Comment

by:learningunix
ID: 34976152
I need a way to keep the socket connection alive so that thread 1 does not throws exception
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 34977011
If you don't want to block on send, then open the socket in non-blocking mode.
Also, you can use write() system call instead of send().

From the send() manpage, regarding blocking, this is what it says:
When  the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-blocking I/O mode.  In non-blocking mode it would return EAGAIN in this case.
0
 
LVL 6

Expert Comment

by:de2Zotjes
ID: 34977593
If you created a thread just to ensure that a connection is not dropped due to inactivity you should instead look at the OS facilities: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.

The very short summary of that howto is that the kernel can take care of this for you. And that you can set this up when creating the socket.
0
 
LVL 53

Accepted Solution

by:
Infinity08 earned 2000 total points
ID: 34977788
A few things that will probably help you figure out what's going wrong, and fix the problem :

(a) make sure that both threads use the same socket (id) - do that by using a shared variable

(b) make sure that both threads use a shared mutex (or other synchronization primitive) to control access to the shared socket

(c) make sure that both threads lock the mutex (if using a mutex) before each use of the socket, and release it as soon as they have finished using it. When using a loop, make sure to do the locking and releasing inside the loop (so as not to lock it for too long)

(d) always check all return values and/or error code for all function calls
0
 

Author Comment

by:learningunix
ID: 34979276
@infinity.

1. Yes both the the thread uses same socket desciptor
2. Before sending I use mutex to lock it and then release the lock
3. The issue is Thread 1 is somehow blocked after sending a large number of data?
4. Because of this my Thread 2 can't get lock on mutex and is not able to send keepalive packet
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 34979414
>> 3. The issue is Thread 1 is somehow blocked after sending a large number of data?

But the question is : where is it blocked and why ?

If it really is the send that is blocking, then ssnkumar's suggestion to use a non-blocking socket (and check all return codes) would resolve this for you.

If it's blocking on the lock, then there might be a deadlock, which you'll have to investigate.

If it's blocking somewhere else, then you need to find out where.

As I said : make sure to check and verify all return and error codes.
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 34981639
> 3. The issue is Thread 1 is somehow blocked after sending a large number of data?
Put a printf() before and after send() call and see if it is blocked on send().
If yes, then either you need to change the receiving socket, so that it does a recv() to get the data.

So, to continue to debug, you should find out, which call is blocking?
0
 
LVL 6

Expert Comment

by:de2Zotjes
ID: 34986256
And again: let the kernel handle this. Keepalive packets are put on the line when needed, but you will not have problems in your applications (server and client) with handling data that was sent as keepalive data.

looks like a typical case of reinventing the wheel..
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 34986303
Sure, de2Zotjes, but it's still interesting to know what caused the issue, because it might be impacting other aspects of the code too.
0
 

Author Closing Comment

by:learningunix
ID: 35037867
locks were not released properly. I found out. Thx
0

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Article by: SunnyDark
This article's goal is to present you with an easy to use XML wrapper for C++ and also present some interesting techniques that you might use with MS C++. The reason I built this class is to ease the pain of using XML files with C++, since there is…
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
The viewer will learn how to user default arguments when defining functions. This method of defining functions will be contrasted with the non-default-argument of defining functions.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Suggested Courses

649 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question