Click here to Skip to main content
15,867,568 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi all,
Some quick background on my application:

The application, designed in vb.net, is for multi-user database information access. Users create and edit entries across several data tables, most of which are related.

I'm attempting to address a concern about multiple users editing the same entries t the same time. My solution is to create a second application which will placed on the machine that hosts my database. Users will log onto this server application when they start their client application.

The server application serves a simple role, inform all connected users when an entry in the database is: LockedForEditing, ReleasedFromEditing, Added, Removed, Updated. It also does some single user communication to register Identity and to respond to queries and to threaten to release a locked entry if a response isn't received in a certain amount of time.

Everything is working pretty well and functioning exactly as planned except for the problem below.

Problem: I keep a list of connected clients and steadily read the socket until information is received. My server doesn't register a lost connection so if a user tries to re-connect using the same username they will be denied access until the server is restarted . I have tried to steadily write to the client sockets a connection signal (1) so that the disconnected socket will raise an error when the write fails. the result is clutter appended to the end of my transmissions. Exaple: QueryServer,QueryID=13,IsEntryLocked,Table1,ID=1...."crap load of squares that can't be interpreted --here--".

Basically, I'm looking for direction on this. Is there some design that I should be fallowing to accomplish what I'm trying to do? Or better yet, a class that is easier to implement that might eliminate some of the need for knowledge of network connections. I'm very inexperienced with network communication and pressed for time on this. Having a temporary cure all until I can sit down and do some more research would be a god send. Thanks in advanced.
Posted
Comments
Fredrik Bornander 18-Oct-13 4:35am    
Can you destroy the current session if a user tries to log on again, so that the latest session is always the valid one?
Mr.TMG 18-Oct-13 18:15pm    
I understand what you're saying. I would however, prefer to inform the application at the time of disconnect as I will also be using this connection to query instruments that are connected and do not want anything to register as connected when actually it's broken.

1 solution

You're thinking in the right direction. You do need to pass a control byte back and forth, and the nice thing about that is that when you get it right you can do some really cool things with the synchronization.


The way I did client server communication was to define a packet, and pass a control byte (with a value of 0) back and forth. If you (the client or server) have the control byte, you can send a packet. If not, you pass the control byte back. If you don't have the control byte, you're listening for a packet.

My packets are made up of a 3 byte header: The first byte is a channel identifier (a number between 1 and 255). The last two are halves of a ushort. The ushort contains the amount of user data trailing the packet header, so the receiving machine knows how many bytes to read before receiving the control byte, and maybe sending a packet of it's own.

You can download my codeproject article and have a look at how I did it here.

Good luck.

- Pete
 
Share this answer
 
Comments
Mr.TMG 18-Oct-13 18:17pm    
Thank you for that link, Pete. I'll have a look.
Mr.TMG 19-Oct-13 0:24am    
You've put a lot of work into this. It's nice. Thank you.
pdoxtader 19-Oct-13 11:01am    
Welcome. Hope it works out for you.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900