SERVER

concepcionsockΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 11 μήνες)

234 εμφανίσεις

SERVER

GROUP 3

Carl Ådahl

Emil Zail

Fredrik Svensson

Henrik Wallin

Niclas Groth








SERVER GROUP


SERVER

IMPLEMENTATION

Implementation tools


-

NetBeans was our IDE.

-

MySQL JDBC driver added.

-

Otherwise plain Java with Swing ”console”.

-

Google Code for team collaboration

-

Mercurial for source control (NetBeans plugin)


SERVER

VISION

Vision

-

DeviceBox[es]


-

Client that “hosts” 1
-
n devices. Each ”device” is


something that can be controlled or measured in the


house.

-

Units


-

User client, anything that speaks our protocol. Web app


server, cell phone, etc.

-

Server purpose


-

Controls communication between Units and DeviceBox


-

TCP + text based protocol (Telnet
-
compatible)

-

Rules


-

Users (Units) connect simultaneously (avg <10).


-

Users (Units) must authenticate with username/pw.


-

DeviceBox[es] connect on different port. No need for


authentication.






SERVER

RISKS



Risks (examples)


-

Server code instability (Medium)

-

The server is the hub of our ”star network”, so if it


fails, no other subsystem will work.

-

Connection lost (Medium)

-

Server bugs cause dropped client connections.

-

This isn't as severe as the previous risk, only one client
affected. (Unless it's the DeviceBox)

-

Too many users (Low)

-

There is no
hard

limit on nr of accepted units.

-

We don't use Java NIO, so each connection has


threading overhead.

-

In practice, we estimate the server scales to enough


users (<=20).


SERVER

DESIGN



Design

-

Early design sketch


SERVER

DESIGN



Design

-

Ended up cutting “cache” of device state in


server. Worked fine without it.

-

Concurrency was the main issue to solve.

-

In reality each
ClientConnection

has two


threads:


1) Listen for network messages (the client)


2) Listen for routed messages (another client)

-

MessageRouter



-

post(), postToAll(), poll()


-

Each client has an ”incoming mailbox”.


-

Thread safe (synchronized access).


-

No scalability issues in practice. Maybe with


50+ clients?



SERVER

DESIGN



Design (UML)







SERVER

DESIGN



Design


-

Overall design mostly unchanged from the


original version to the final implementation.

-

Small adjustments (designed as we solved


issues).

-

Umbrello as UML tool.

-

Able to reverse
-
engineer to update diagram for


documentation.

SERVER

TESTING



Testing

-

Failed to do proper unit tests. Not much was


specified about any kind of testing.


-

Tested ad
-
hoc as we developed.

-

To simulate a Unit or DeviceBox, we used


Telnet and manually entered protocol messages.

-

Later, integration testing was done by meeting


with other groups and letting them connect.

-

Found some server bugs this way, fewer than we


expected. Positive.

-

Formal written test cases would have helped


us catch bugs before integration testing.






SERVER

CONCLUSIONS



What we did right


-

Started early.

-

Documented early.

-

Designed early.

-

Chose simple solutions that fit the requirements.

-

Source control was invaluable. Everyone


could work in parallel and merge their code with


the Google Code repository.

-

Dependencies on other teams were eliminated


by stubbing etc. (Except protocol.)

-

Successful implementation.



SERVER

CONCLUSIONS



Things that could have been better

-

Requirements. (Vague.)

-

Testing. (Weak, ad
-
hoc.)

-

Implementation lagged behind.


-

Waited for protocol spec.


-

Should have rushed collaboration with Protocol


group to figure out details relevant to server.

-

Much less activity between meetings than during.


-

Not every member fully ”in the loop”.


-

Could have communicated better.


-

More explicit division of responsibility?


-

In retrospect needed more
explicit

feedback from


teachers (documentation/planning areas).